Writing Maintainable Test : Enforcing Test Isolation - The Shared State Corruption Anti Pattern.

Hello , we continue talking about writing maintainable tests and the advices Roy osherove gives in his book The Art Of Unit Testing.

Shared State Corruption Anti Pattern

This one is about sharing the state of an object across multiple tests , but we expose our tests to dependencies. If one test modify the state of the object that the second test depends on , our test is going to fail.

Look at the C# code below ( from the book )

[TestFixture]
public class SharedStateCorruption
{

  // defines Shared Person state
  Person person = new Person();
 [Test]
 public void CreateAnalyzer_GoodFileName_ReturnsTrue()
 {
  person.AddNumber("055-4556684(34)");
   // Changes shared state
  string found = person.FindPhoneStartingWith("055");
  Assert.AreEqual("055-4556684(34)", found);
 }
 [Test]
 public void FindPhoneStartingWith_NoNumbers_ReturnsNull()
  {
   string found =
   person.FindPhoneStartingWith("0");
   // Reads shared state
   Assert.IsNull(found);
  }
}

We all agree that the second test is going to fail because it expects NULL but it will not be the case , because the first test has changed the state of our object by using the person.AddNumber("055-4556684(34)") instruction .

So what are the patterns of this anti pattern ?

1. Not Setting Up state before each test : A developer doesn’t set up the state required for the test or assumes the state was already correct.

2. Using Shared State : A developer uses shared memory or external resources for more than one test without taking precautions.

...And ( we all have guess the solutions ) the solutions are:

1. Not Setting Up state before each test : Either use a setup method or call specific helper methods at the beginning of the test to ensure the state is what you expect it to be.

2. Using Shared State : you don’t need to share state at all. Having separate instances of an object for each test is the safest way to go.

What i think about these solutions

I think they are great one , especially having a separate instance for each test , by doing this when an error occurs we can focus on one test , one object instance , in fact the only world :) of our unit test..

Thanks for Reading ;)