4.6.1 MVC Testing

Detail the challenges of asynchronous component in testing

A major problem resulting from a complex View is the difficulty of testing. Visual components tend to be more complex to test, because they require simulation of User interaction. Toolkits provide techniques to create events programmatically, but their handling depends on the event loop being executed. The blocking nature of its execution makes it impractical in a test setting.

Testing a GUI application is generally complex, due to the large number of interactions that the user may potentially choose to perform. Manual testing is tedious and error-prone, and simulating user events can open problems relative to their intrinsic asynchronous nature, and the visual nature of the result.

A sensible approach is to leverage the MVC structure to attack the testing problem in a programmatic, and possibly synchronous way.

In general, you should be able to test or even use the model independently of the controller and views. In fact, the model should be able to work without any controllers or views implemented at all. It’s a completely separated layer with no dependencies toward GUI representation, widgets, or strategies to apply the changes. If this is not the case, then you have a code smell that needs refactoring. There are however exceptions to this rule [7]. For example, suppose your model is representing the state of a drawing program. The shapes that are inserted in the model are actual Shape objects that are graphical in nature, and it would make sense to assign to these objects the responsibility of drawing themselves on the view. This is practical, but it can backfire: it requires the objects to know about the specific view’s details about how to draw itself onto it, meaning that a different view might not be compatible. Assigning representation responsibilities to model objects is a rare occurrence that can always be worked around, for example separating the mathematical description of the Shape (e.g. the corners of a rectangle) from the drawing logic (e.g. the actual graphic calls that draw the rectangle on the screen) and move this drawing logic in a Renderer class.

A view that acts on a widget knowing nothing about the model. View “adapter”

Mock view: it attaches to the model like a normal view, but has no GUI and can be probed. Fixture model: a model with well defined, well known data that can be attached to the view. The view should draw exactly what we know from the fixture model.

Microsoft Visual Testing Sending events with xtest, or with the widget level interface. Sporadics due to change in layout, running the screensaver.

asynchronous tests tend to be slow (you need to perform an action, then wait for the result that may come and sporadically broken, because of race conditions. Favor synchronous testing, restrict asynchronous.

Test of components that are hard to test should be minimal, and the behavior of these components should be minimal as well.

You can perform tests of graphical components by pushing events into the GUI toolkit event queue, but again, they tend to be brittle and asynchronous.

Watir, WatiN, Selenium