Non-UI Automation of WPF MVVM Applications
MVVM seems like still walking the ramp. Couple of my previous assignments has been spent deciding automation strategy for MVVM applications. Discussing among fellow testers, only to reach one consensus. Let’s create UI tests in CodedUI or Teststack White, mission accomplished.
I kept having to ask myself questions, making so many UI tests will lead to high maintenance, execution time will be too high. How will we integrate it in our continuous Integration tool? It doesn’t seem right. Is there a way to test functionality without involving UI. After toping up my knowledge about MVVM, found a solution which is faster, less maintenance and execution time for tests is 0.1-0.5 milliseconds.
Our Test Pyramid:
- Unit Tests: Unit Test coverage is above 90% for us. Testing functionality inside individual ViewModels.
- Integration ViewModel Tests: That’s where we have innovated a bit. To test end to end flows, we need to traverse across more than one ViewModel. To accomplish it we used the Dependency Injection Containers(IOC) (Will make things easier if you use the one developers used. You can copy all the bindings or call there implementation). Now we have a container with all ViewModels in it. Mock the UI(Views) and you are all set to run end to end tests covering more than one View Model. Tests run very fast and fit to be added to continuous Integration tool. Any small logic change in view model will be flagged right away.
- UI Tests: To prove bindings are working fine we have created a very skinny set of UI tests they just validate UI elements. Functional tests are pushed down to ViewModel level.
Advantages of ViewModel Integration tests:
- Faster tests , taking milliseconds to complete
- Tests are robust.Don’t face issues like synchronisation problems we face in UI tests.
- Can be integrated with CI/CD.
- Stable tests , less maintenance required than UI tests
Disavantages of ViewModel Integration test:
- Need a skilled tester who is comfortable doing bit of development.
- Think twice, if your fellow developer is planning code refactoring. You might end up fixing loads of tests broken due to refactoring.