2

So, I am working on a new feature for our WPF application. I would like to use BDD especially since the interactions are clearly defined already. I have written specs for web projects, but never a desktop application. So, my problem is that I would like to be able to test state, and avoid UI scraping, but I do not see a way to do this?

Here is the problem:

I see that I have to start the application, login, and then perform the actions and scrape the screen for the state (all using UIAutomation)

I would like to be able to get the state from the code, however. So, the best I can think of is to drive it through the MVVM structure. However, I guess the problem that I see is that some of the flow from one form to the next comes through the UI bindings, so is there a way to do that via MVVM? Do I have to run this all through my UI?

I keep spinning myself around trying to think how to implement this. Is there a best practice for the above?

Justin Pihony
  • 66,056
  • 18
  • 147
  • 180

2 Answers2

3

The best way to do this is to tier your testing. I find the best way to do this is to ignore the view layer, write BDD specs that describe your functional interactions, and then use unit tests to drive out your model, view model and controllers.

First, by ignoring the view, you reduce your test fragility. If you don't describe your tests in terms of clicking buttons and using menu items, you don't have to rewrite the tests when the UI changes. And to be honest all you really gain by doing this is checking that you have bound your commands properly to your UI elements.

So instead consider this approach, and I'm going to use an alarm program as an example;

  1. First define a feature, e.g. When it is the correct time Then sound an alarm. This will help you flesh out your logic and define your model classes. Normally I will build multiple unit tests to help build the logic for each feature.
  2. Derive further features that start to involve the user interactions with the UI. Don't describe these as you would to somebody who isn't used to using computers, clicking buttons and entering text, but more how you might tell somebody who is proficient, e.g. When you set the alarm time to 9am. Write/Refactor your SpecFlow bindings to call the ViewModel Commands and set/get the ViewModel properties.
  3. Wire your View Bindings to your ViewModel.
  4. Change your UI around, and revel in the fact that your tests still all pass.

I've most recently used this technique on a UI where each client talks to multiple servers. I have some unit tests that mock out everything so that only a method gets called. Moving up I have some tests where the client-server communications are simplified by instantiating both parts and coupling them directly in my test, and finally I even have a couple of tests where we test failure of one comms system (server pushes to all clients) and fall back to another (each client polling the active server) which requires running a local server on the machine. The fact that I can do this in the back end, mirrors what I'm doing in my UI and testing only what is relevant at each stage.

AlSki
  • 6,868
  • 1
  • 26
  • 39
  • I finally came across a SO that was what I am looking for: http://stackoverflow.com/questions/10356005/is-bdd-really-applicable-at-the-ui-layer My concern with your answer is that it does not guard against bad wiring of the UI. Yes, the tests are brittle, but this is a WPF app that isn't going to change enough. It just seems that most of what you are talking about still is unit testing. So, I am going to go with unit tests first, and then work on testing the UI via stories later. – Justin Pihony Apr 01 '13 at 18:26
  • Justin, As long as you are testing then you are doing something right. Everybody has their own sense of when they are testing correctly and if what you have works for you then that is great. In fact I'd be very interested to hear how you get on with how your resting works out. Good luck. – AlSki Apr 05 '13 at 10:46
0

What about using Specflow with Coded UI? We are starting to trial this out so will let you know how we get on. At the moment we have trailed it out from a technical perspective and it seems to work. Though I have reservations about this overall approach to testing UIs given there likelihood of change. Take a look http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/

DisscCoder
  • 569
  • 1
  • 4
  • 7