Step by Step screencasts to do Behavior Driven Development on WCF and UI using xUnit

For those who have missed my presentation, I am trying to encourage my team to get into Behavior Driven Development (BDD). So, I made two quick video tutorials to show how BDD can be done from early requirement collection stage to late integration tests. It explains breaking user stories into behaviors, and then developers and test engineers taking the behavior specs and writing a WCF service and unit test for it, in parallel, and then eventually integrating the WCF service and doing the integration tests. It introduces how mocking is done using the Moq library. Moreover, it shows a way how you can write test once and do both unit and integration tests at the flip of a config setting.

Watch the screencast here:

The next video tutorial is about doing BDD to do automated UI tests. It shows how test engineers can take behaviors and then write tests that tests a prototype UI in isolation (just like Service Contract) in order to ensure the prototype conforms to the expected behaviors, while developers can write the real code and build the real product in parallel. When the real stuff is done, the same test can test the real stuff and ensure the agreed behaviors are satisfied. I have used WatiN to automate UI and test UI for expected behaviors.

 

Hope you like it!

12 thoughts on “Step by Step screencasts to do Behavior Driven Development on WCF and UI using xUnit”

  1. I love the concept of BDD; the quality of the audio is so bad that I will not watch it. Also, having a downloadable wma provides me with the option to increase playback rate. Pls take these things into consideration.

  2. Omar, the mp4 is better, but it still has the noise.

    Next to that I really don’t like the fact that you code first and test later. Especially considering you are doing something trully good: introducing BDD. Using BDD is not about development, but about design.

  3. The only code first here is defining the interface (service contract), which is part of the design work. The interfaces are handed over to test engineers to get started with their test work.

    Remember, the idea here is to maximize parallel development. When you have an armada of test engineers to test your component, you need to empower them as early as possible in the development life cycle. So, as a developer/desginer, you need to pass them some code which makes their tests practical.

    1. You test the mocked interface first to confirm that the interface works as expected and you write all the test code against the correct expectations. You can do this before developers deliver you the real code. Then when the real code is delivered, you swap the mocked interface with the real interface implementation and if the implementation is right, it would all pass. If it does not pass, then either developer did it wrong, or the test has wrong expectation from what’s the reality.

  4. But if the behaviors are being flushed out in parallel with development, then they are not driving the development. The point is not to verify the code (though that is end result), but to let the behavior drive what code you need to write. This process is meant to be highly interactive, not done in isolation.