Writing Maintainable Test : Enforcing test Isolation

The next few days i will share some good advice that Roy Osherove gives in his book The Art Of Unit Testing about Writing maintainable unit test.

in this series i will talk about test isolation

What is the purpose of a unit test ?

I share the same definition of Roy , the purpose of a unit test is to test a use case in his world , we should really take the ** in his world ** seriously.

Enforcing Test Isolation

The basic concept is that a test should always run in its own little world, isolated from even the knowledge that other tests out there may do similar or different things.

so it is just about that, next we will talk about the first anti pattern about maintainable unit test , ** Constrained Test Order **

Anti Pattern Constrained Test Order

Indeed when we expect our tests to be run in a certain order, we are saying indirectly that our tests have some dependencies each other , and if the monday morning our tests are passing maybe the friday before going in week it will not pass. look at what Roy says
<< This problem arises when tests are coded to expect a specific state in memory, in an external resource, or in the current test class—a state that was created by running other tests in the same class before the current test >>

Roy presents two patterns about that anti pattern :

1. Flow Testing : The fact that the developer wants his tests to run in a specific order.

2. Laziness in Cleanup : A developer is lazy and doesn’t return any state their test may have changed back to its original form.

...And the solution to these patterns:

1. Flow Testing : I think like him that if our tests should run in a specific order , so we are in the domain of ** integration testing** so for testing that flow choose Integration Testing( i will talk about that in another post maybe :) )

2. Laziness In Cleanup: look what R. Osherove says , i know it is some kind of hard but read If you’re too lazy to clean up your database after testing, your filesystem after testing, or your memory-based objects, consider moving to a different profession. This isn’t a job for you

This is all for Today :). Thanks for reading , and we should not forget , our code is not for us , it is for future readers , so even in writing our unit tests we should think abou them.