Question

I’ve got a complex part of a web application, and we’re starting now to unit test it in order to ensure that everything works fine, and if any changes will be made, the tests will be there to check whether we broke anything.

This portion of our app is a sort of wizard: You go from step 1 to step N. Each step can fork in different ways depending on what the user chooses. Each step can also contain either only 1 item or a collection of items, like this:

• Step 1: Are there items of type X? If yes, how many?
  • For each item declared -> form to input item data
• Step 2: Are there items of type Y? If yes, how many?
  • For each item declared -> form to input item data (may contain references to items declared in step 1)

etc. It’s not all like this, there are exceptions, but it’s just to give an idea of how it is. Now this procedure isn’t forward-only. The user must be able to jump back to previous nodes and apply changes, add items or remove items from collections, etc. and the software must remember what was the last step he completed before jumping back, so when he’s done he can go on.

For unit testing purposes, I am thinking that I can’t have standalone tests: if you haven’t completed previous steps, you don’t have the data for successive steps. Thus I was thinking of writing ordered tests.

I also read that a best practice is to “have the test be independent from one another”, and what I thought to do is going against this.

The sample tests I wrote are green if run as an ordered test, but only the first one is green if run as standalone tests.

Now I’d like to hear opinions and if anyone has a correct way to approach this situation.

Answer 1

Each test should indeed be independent of each other. If Test B depends on Test A executing before it, then you have potentially very flakey tests on your hands. In your situation, I’d prefer to SetUp Test B by pre-configuring a context.

What I mean is, whatever state Test A leaves the system after it has completed, use that to setup the context for Test B e.g.

public void TestB()
{
    // Arrange.
    SetupSystemLikeTestAHadJustRun();

   // Act.
   // Do your tests.

   // Assert.
}

By having a known, fixed, context at the start of the test, you stand a much better chance of having a good suite of tests.

Alternatively, if you have heard of BDD (Behaviour Driven Development) you could a use a BDD tool like SpecFlow or NBehave (for .NET) or Cucumber for Ruby. Using BDD allows you to be more expressive in your testing.