Importance of unit testing my Views when using the MVVM pattern?

When using the MVVM pattern to structure your WPF application you should get all your business logic out of the View and code-behind files. Doing it properly the View itself will be a simple facade with Data Bindings and Command Bindings to the ViewModel classes - which is where the magic happens.

One key benefit from structuring your applications using the MVVM pattern is that you get to test your code properly in the ViewModel layer, and hence you're able to unit test the essential parts of your system. However, there is still potential for bugs in the View. E.g. "Does clicking this button actually trigger this specific function with the expected parameter?", etc.

What would one ideally do about the functionality开发者_如何学编程 in the View regarding unit testing? Assuming that you'll get it right, and don't spend time unit testing it? Or should I actually have tests for this too? How should these be created? ..

As you say, you test all the logic and behaviour using the ViewModel, with behaviour including "visibility" calculations etc.

Once you've got all that under test then testing the view is much less of a task - you are essentially testing that things are "wired up" right. This type of testing is simple for a manual tester, as they are essentially testing things appear and "do stuff" when they're clicked (an over simplification, but you get the idea).

If you want to automate view/interactive testing then take a look at Project White, that will let you automate your application with very little work. One advantage of making your project work nicely with White is you're also making it more accessible for assistive technologies.

For WPF gui testing try IcuTest.

You can easily create unit tests that shows windows and clicks buttons.

One of the reasons MVVM is so important is that regression-testing UIs is a problem that's difficult and expensive to solve. The great majority of UI test conditions are in the form "when I perform this action, I should see this on the screen," and automating that second part is non-trivial.

From a testing perspective, what MVVM gets you is that the body of unit tests for a view model essentially functions as a contract. It isn't, formally, a contract, but it functions like one. If you've tested your view properly, and your view model tests are sufficiently detailed, you don't need to retest your view every time you change your view model; as long as the view model passes its tests, its behavior (as far as the view is concerned) should not have changed.

But in order for that to work, you have to have confidence in your view model tests. And it won't work 100% of the time.