Thursday, February 05, 2009

TotT: Be an MVP of GUI Testing

With all the sport drug scandals of late, it's difficult to find good role models these days. However, when your role model is a Domain Model (object model of the business entities), you don't need to cheat to be an MVP--Use Model-View-Presenter!

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.



The View becomes passive, delegating to the Presenter.

public CongressionalHearingView() {
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.

Remember to download this episode of Testing on the Toilet and post it in your office.


  1. Hi

    I 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?

  2. Great post!

    Once 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:

  3. The post is great and it's covering an issue that most of us face; testing user interfaces.

    The 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.

  4. 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.

    The 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.


The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.