In addition to the unit tests we’re already writing for each of our core classes, we should also write some integration tests to ensure our types interact properly.
Naturally, this gives rise to a simple question: How should we structure our integration tests?
For those who haven’t seen it before, the Gherkin language breaks the test down into three parts. First, you set up the context for the test (Given), then you take an action (When), and finally, you check for the expected outcome (Then).
To illustrate, here’s how one of the WordTutor tests could be written, to verify that the transitions between screens work properly:
The very popular SpecFlow project is one way to write tests in this style - but I want to experiment with a different approach, one that doesn’t require plugins for Visual Studio or separate compilation steps.
Playing around with ideas for a pure C# technique, I’ve discovered that some of the features recently introduced into the language make it quite possible.
To this end, I’ve published a small experimental library on NuGet that provides a Given-When-Then syntax for defining/structuring tests.
Here’s an example of the library in use, expressing the same test as shown above.
This test method starts with two lines to establish the current context for the test - with the vocabulary set “Music Pace” loaded and the browser as the current screen. After that, we apply the action “Open New Word Screen”, and lastly check that the current screen has changed to the expected one.
If you look at the associated code, you’ll see the tests are isolated in
VocabularyMaintenanceInteractionTests while all the building blocks can be found in the base class
InteractionTestsBase. This separation makes the tests themselves easier to read, and will (hopefully!) make it easier to add new integration tests as we go forwards.