Martin Fowler - GUI Architectures. Part 5
The previous part is here . Original article here .
This is the last part.
A few years ago in the field of programming a new fashionable trend appeared - to write a self-testing code. Despite the fact that I am the last person to contact on fashion issues, I am completely immersed in this idea. In addition, among my colleagues there are many fans of xUnit frameworks, automatic regression tests, Test-Driven Developement, Continuous Integration, and other similar obscure terms.
It is believed that one of the problems of writing self-testing code is writing tests to user interfaces. Many people think that testing the GUI in terms of complexity is somewhere between “very difficult” and “impossible”. This assessment comes from the fact that user interfaces are closely related to the common UI environment and therefore it is difficult to isolate them into one piece and test them in pieces.
')
However, sometimes such an estimate is too high. You can achieve amazing results if you start creating custom elements with handles and manipulating them in the test code. However, this alone is not enough and there may be cases that cannot be tested. For example, cases of complex interaction of elements, multi-threaded environment or slow execution of the tests themselves.
The solution to the described problem is the design of user interfaces, where the number of functionalities for hard-to-test objects is minimized. This approach is clearly described by Michael Feathers in his work The Humble Dialog Box . Gerard Meszaros summarizes this understanding into the idea of ​​a simple object ( Humble Object ) - any object that is difficult to test must have a minimum of functionality. Thus, if we fail to create tests for such an object, the chances of getting an error in its behavior are also minimized.
In The Humble Dialog Box , the presenter from the MVP model is used. However, it has much greater capabilities than the one described in the basic MVP. Presenter not only determines how to respond to events, but also deals with filling data with user elements. As a result, it turns out that user elements no longer need to have access and view the model. They form a passive view ( Passive View ), which is entirely controlled through the presenter.
The described approach is not the only one that can make the presentation simple. Another approach is to use the Presentation Model pattern. Its small drawback is that the controls will need to be given more functionality, which will allow them to become attached (map) to the view model.
The key to both approaches is that the tests have to be written only for the presenter or presentation model. They test the main “risk” functionality, while the “difficult-to-test” controls themselves are left aside.
Read more about the view model. The view model must implement all the relevant logic. All user events should be redirected to the view model. All the controls need to do is bind to its corresponding properties. Tests will test all the functionality of the presentation model without the need for any control. The only risk remains only in the binding elements to the model. If we consider that the binding functionality is very simple to implement, you can close its eye testing. True, in this case, the view is not as “simple” as it could be in the Passive View approach. However, the difference is very small.
In the case of the passive view ( Passive View ), as I have already said, the lack of binding functionality removes the risk that is present in the case of the view model. The cost of not taking this risk is the need for double testing ( Test Double ), which is needed to emulate the behavior of the screen during the execution of tests. This means that you will need to create and configure some kind of additional software mechanism.
A similar solution is also present in the Supervising Controller pattern. Some risk of an error occurs when a view is forced to bind (as is the case with the Presentation Model . The advantage of this binding, by the way, is that it is all declarative. The number of such bindings in Supervising Controller will be less than in the view model as Supervising Controller is engaged in the transfer of data (in the most complicated cases and scenarios) to the controls explicitly defined in its code, while the model of representation forced to solve their complex based scenarios arias by binding mechanism.
If you want to read articles that develop the ideas described, check out my bliki
Vasily Bykov generously shared with me his copy of Hobbes - the implementation of the Smalltalk 80 version 2 platform (1980!), Which can be run on the modern version of VisualWorks. In this copy I was able to create examples on live, original MVC, which helped me a lot to understand how it worked and was used in those times. By the way, many people negatively perceive the use of virtual machines. I wonder what they would say if they saw how I work in Smalltalk 80 on a virtual machine written in VisualWorks that runs on a VisualWorks virtual machine that runs on Windows XP, which is running in VMware, which is running in Ubuntu?
July 18, 2006: first publication on the site
All rights reserved to Martin Fowler. All rights reserved.
This is the last part.
Humble View (simple view)
A few years ago in the field of programming a new fashionable trend appeared - to write a self-testing code. Despite the fact that I am the last person to contact on fashion issues, I am completely immersed in this idea. In addition, among my colleagues there are many fans of xUnit frameworks, automatic regression tests, Test-Driven Developement, Continuous Integration, and other similar obscure terms.
It is believed that one of the problems of writing self-testing code is writing tests to user interfaces. Many people think that testing the GUI in terms of complexity is somewhere between “very difficult” and “impossible”. This assessment comes from the fact that user interfaces are closely related to the common UI environment and therefore it is difficult to isolate them into one piece and test them in pieces.
')
However, sometimes such an estimate is too high. You can achieve amazing results if you start creating custom elements with handles and manipulating them in the test code. However, this alone is not enough and there may be cases that cannot be tested. For example, cases of complex interaction of elements, multi-threaded environment or slow execution of the tests themselves.
The solution to the described problem is the design of user interfaces, where the number of functionalities for hard-to-test objects is minimized. This approach is clearly described by Michael Feathers in his work The Humble Dialog Box . Gerard Meszaros summarizes this understanding into the idea of ​​a simple object ( Humble Object ) - any object that is difficult to test must have a minimum of functionality. Thus, if we fail to create tests for such an object, the chances of getting an error in its behavior are also minimized.
In The Humble Dialog Box , the presenter from the MVP model is used. However, it has much greater capabilities than the one described in the basic MVP. Presenter not only determines how to respond to events, but also deals with filling data with user elements. As a result, it turns out that user elements no longer need to have access and view the model. They form a passive view ( Passive View ), which is entirely controlled through the presenter.
The described approach is not the only one that can make the presentation simple. Another approach is to use the Presentation Model pattern. Its small drawback is that the controls will need to be given more functionality, which will allow them to become attached (map) to the view model.
The key to both approaches is that the tests have to be written only for the presenter or presentation model. They test the main “risk” functionality, while the “difficult-to-test” controls themselves are left aside.
Read more about the view model. The view model must implement all the relevant logic. All user events should be redirected to the view model. All the controls need to do is bind to its corresponding properties. Tests will test all the functionality of the presentation model without the need for any control. The only risk remains only in the binding elements to the model. If we consider that the binding functionality is very simple to implement, you can close its eye testing. True, in this case, the view is not as “simple” as it could be in the Passive View approach. However, the difference is very small.
In the case of the passive view ( Passive View ), as I have already said, the lack of binding functionality removes the risk that is present in the case of the view model. The cost of not taking this risk is the need for double testing ( Test Double ), which is needed to emulate the behavior of the screen during the execution of tests. This means that you will need to create and configure some kind of additional software mechanism.
A similar solution is also present in the Supervising Controller pattern. Some risk of an error occurs when a view is forced to bind (as is the case with the Presentation Model . The advantage of this binding, by the way, is that it is all declarative. The number of such bindings in Supervising Controller will be less than in the view model as Supervising Controller is engaged in the transfer of data (in the most complicated cases and scenarios) to the controls explicitly defined in its code, while the model of representation forced to solve their complex based scenarios arias by binding mechanism.
Further
If you want to read articles that develop the ideas described, check out my bliki
Acknowledgments
Vasily Bykov generously shared with me his copy of Hobbes - the implementation of the Smalltalk 80 version 2 platform (1980!), Which can be run on the modern version of VisualWorks. In this copy I was able to create examples on live, original MVC, which helped me a lot to understand how it worked and was used in those times. By the way, many people negatively perceive the use of virtual machines. I wonder what they would say if they saw how I work in Smalltalk 80 on a virtual machine written in VisualWorks that runs on a VisualWorks virtual machine that runs on Windows XP, which is running in VMware, which is running in Ubuntu?
Significant revisions
July 18, 2006: first publication on the site
All rights reserved to Martin Fowler. All rights reserved.
Source: https://habr.com/ru/post/54034/
All Articles