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