Our small team writes desktop apps using WPF + Prism. Most of the team members are not so familiar with professional software developing process. I'm trying to adopt some agile techniques to make the existing process more professional and bring more quality to our products. The one of basic conception of the agile process is automated and regular testing. We already have two levels of tests:
- Unit tests. Classes in isolation as always, nothing special.
- "Integration" tests. Since the MVVM pattern with IoC container is used, it is possible to wire up the whole application and interact with it through ViewModels like the UI does. In these tests we test logic of all features from use cases.
Now I'm trying to automate UI tests, since we don't have testers or QA team, and developers have to test features themselves. But these tests are pain in the ass. Writing and supporting automated UI tests are so time consuming. Executing them takes a lot of time too. And I have some uncertainty. Are automated UI tests so needed at all? And if they are, what should be tested?
A little research gives me two ideas:
Test only UI features.
This idea is described here.
Assuming you have good test coverage of the actions themselves via unit or integration tests, the goal of automated UI testing is to insure that the widgets are all making proper calls to the underlying actions.
In our case it means to mock all of the ViewModels and then test all windows to have proper binding, command parameters and so on. Could be considered as tests of UI in isolation.
Have tests for important features only
It means to automate only few most important use cases of the program. These few tests can be used as basic acceptance tests. And these tests should be only "everything is ok" scenarios, so they don't test malfunctioning situations.