Should I unit-test my view in MVP(or VM) or how to keep the code in the view to a minimum?

Question

I use Model-View-Presentation Model in my application and I am wondering whether I need to create unit tests for the view. (I am on .net 2.0 WinForms)

Now typically the view should be so simple that it should not be necessary to create unit tests for it. At least that's the idea I got from the goal of having the separation of View vs. Presentation Model (PM). And for the most part that is true in my code as well.

However, there are cases where I can't seem to avoid some logic in the view. These typically have to do with Drag & Drop processing or advanced UI effects (imagine you're dragging a grid row and the datagrid shows placeholder with other rows shifting in real time to indicate you can drop it there).

The other thing is sometimes it seems to me it's more efficient to work with the control itself than to work with the PM and have the databinding reflect the change back out to the control. For example, I have a datagrid and let's say I moved a row from index 5 to 3. I can invoke a method on the PM and have the grid reflect the change via databinding. Or I can just do it on the control. The difference is that the former method forces the control to rebuild itself from scratch while the latter does not.

What are your experiences?

Answer 1

Any time you have logic that might go wrong you should probably write a test for it (if you can). That being said, you can probably have a pass on most of the UI if it truly does not have any hand coded logic. There is not much point in testing form mappings for each form as long as the form mapping system is either under test or is from Microsoft or some vendor

Tragically logic can sometimes leak into the view. A good way to help avoid this is to write functional tests using something like Fitnesse (yes there is a .NET version). Fitnesse is designed to test the app all the way through, as an alternative UI and when done right makes it hard for people to put something in the view.

You can also do tests of these sorts in a unit testing framework but I find the seperation to be helpful, plus Business people can help write and run the tests (because they are in wiki format).

Answer 2

If you have some specialized logic (like drag&drop you mentioned) in your views, you can still move it out into separate class(es) - services, which can then be unit-tested in isolation. Sometimes you will need to refactor (or generalize) the code to achieve this, though. But the idea is to keep the view code as thin as possible, so that all of the other code is unit-testable.

And if you really want to cover views with tests, you can still use some WinForms GUI testing frameworks like White (although such testing is much more difficult and costly than simply writing unit tests with mocks).

Here's a good source about WinForms, MVP and unit-testing: Presenter First: Organizing Complex GUI Applications for Test-Driven Development

Answer 3

I think you're on the right track with keeping business logic out of the View. That said, I see nothing wrong with presentation logic in the View.

Personally I try to keep my Views as lean as possible, use data binding whenever I can, and generally test presentation logic manually (running the application and putting it through its paces).

In my opinion, unit tests for non-visual classes are extremely valuable. There is also value in writing user acceptance, functional, and/or integration tests that cover the interactions of all or part of the system; tools such as FitNesse (as ryber mentioned) are geared towards these. Finally there is GUI testing; while automating this for web sites may provide some value, I feel the test-maintenance costs outweigh the benefits when it comes to WinForms.

However I'm not an expert. I'd definitely suggest researching what testers (not marketers) say about GUI testing and make up your own mind.