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.