If your views are dumb then you are doing it right. This means the only thing you views will define is the mapping between the UI events of the view and the logical events of the presenter and vice-versa. This means that the only way to test the View is by looking at the actual UI and making sure that the mapping is done correctly. This means that for the most part the View part is just an adapter – it takes a button click, or a menu choice, or a gesture, or a text (CLI), or voice instruction{IVR}, or a dial tone (DTMF), a function call (API), or an HTTP command (another type of API), or an email message (yet another type of UI), and converts them into a user event – e.g., SEARCH(). In the other direction – it takes a user interaction – e.g., Show Search Result(), and turns it into the—setting of text into a text field, or a list into a list box, or a generated voice, or an email, or a function response, or an email response, or ah HTTP reply, or whatever, depending on the type of interface your are implementing.

?

This means that the View is extremely simple, and that the Presenter (or Controller) has no idea what UI is. In fact, it defines its own ABSTRACT, domain specific, UI which you mock to test the Presenter and implement for every UI.

?

Where this becomes interesting is under two circumstances:

1.?????? The UI has specific UI interaction that need to be tested – i.e., when you’re implementing specific UI widgets – e.g., a List box (Scrollable), or Drag and drop, in which case you’ll find that the View can be further separated into its own MVP, but that this time the domain is not the user’s domain but rather the UI domain. This will allow you to define abstract operations like ‘Show Scroll Bar’ or ‘Mouse Click’, which you can mock.

2.?????? Internationalization – And other Skin related attributes like colors, fonts, etc. These are obviously UI specific, hence not meaningful to the Presenter, but should still be testable. If you want these to be fixed, you can just test them by inspection (automated of manual). If however you want to them to change (as in i18n or locale information) then these values come from the Model in the UI MVP.

?

?

So -?

[ Model ] == [ Presenter ] == [ View]??

is the application view, where the only difficult thing to test is the view (need to test with real UI).

But, if you have an specific UI interactions it will really look like –

[ Model ] == [ Presenter ] == [[ uiModel ] == [ uiPresenter ] == [ uiView ]]

?

Which gives you two new layers of mocking and easy testing, if you need them.