DEV Community

Cover image for Writing Maintainable Test : Enforcing Test Isolation - The Shared State Corruption Anti Pattern.
DevByJESUS
DevByJESUS

Posted on

1

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);
  }
}
Enter fullscreen mode Exit fullscreen mode

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 ;)

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read full post →

Top comments (0)

Postmark Image

Speedy emails, satisfied customers

Are delayed transactional emails costing you user satisfaction? Postmark delivers your emails almost instantly, keeping your customers happy and connected.

Sign up