TotT: Be an MVP of GUI Testing
MVP is very similar to MVC (Model-View-Controller). In MVC, the presentation logic is shared by Controller and View, as shown in the diagram below. The View is usually derived directly from visible GUI framework component, observing the Model and presenting it visually to the user. The Controller is responsible for deciding how to translate user events into Model changes. In MVP, presentation logic is taken over entirely by a Supervising Controller, also known as a Presenter.
MVC

MVP

The View becomes passive, delegating to the Presenter.
public CongressionalHearingView() {
testimonyWidget.addModifyListener(
new ModifyListener() {
public void modifyText(ModifyEvent e) {
presenter.onModifyTestimony(); // presenter decides action to take
}});
}
The Presenter fetches data from the Model and updates the View.
public class CongressionalHearingPresenter {
public void onModifyTestimony() {
model.parseTestimony(view.getTestimonyText()); // manipulate model
}
public void setWitness(Witness w) {
view.setTestimonyText(w.getTestimony()); // update view
}
}
This separation of duties allows for more modular code, and also enables easy unit testing of the Presenter and the View.
public void testSetWitness() {
spyView = new SpyCongressionalHearingView();
presenter = new CongressionalHearingPresenter(spyView);
presenter.setWitness(new Witness(“Mark McGwire”, “I didn't do it”));
assertEquals( “I didn't do it”, spyView.getTestimonyText());
}
Note that this makes use of a perfectly legal injection -- Dependency Injection.
Hi
ReplyDeleteI enjoy the blog!
HW IP verification has a lot of interesting tools and methodologies such as for instance constrained random testing. Another interesting aspect of this is that it enables metric driven verification since not only line and branch code coverage are measured but also functional and cross functional coverage.
Another interesting aspect of this is that there are tools that inserts errors to measure the quality of testing.
I wonder what is your view of the future of SW testing?
Great post!
ReplyDeleteOnce you get your feet wet with MVP, be sure to check out the Presenter First pattern for an intentional, testable approach to Model-View-Presenter:
http://www.atomicobject.com/pages/Presenter+First
The post is great and it's covering an issue that most of us face; testing user interfaces.
ReplyDeleteThe main problems / issues in any approach I have seen that is not in depth explained is how you wire together the various MVP triads in a project, how to communicate between them and how to set them up (especially in C++ that doesn't support garbage collection)
karlin I am a follower of the Presenter First pattern but I would like to see some more elaborate explanation on how it is different from the MVP pattern presented in this TotT. Some of the issues above are explained in the papers published by Atomic Object (like communication between presenters) but there the majority of issues I described above are still a bit unclear to me.
This is a great TotT, and I used this about 4 months ago while writing testable GWT (Google Web Toolkit) code. I and many others would enjoy a post particularly on GWT testability best practices.
ReplyDeleteThe way MVP applied to my GWT example is I only let the views know about GWT widgets. The M and V wouldn't ever know about the widgets. They just responded to events and dealt with interfaces to the widgets. Then presenters and models can be junit tested (very very fast), and only the view needs the slower GWTTestCase.