The pillars of good tests in C#

Encoder Quick Response Code in C# The pillars of good tests

Duplication in our unit tests can hurt us as developers just as much as (if not more than) duplication in production code. The don t repeat yourself (DRY) principle should be in effect in test code as in production code. Duplicated code means more code to change when one aspect we test against changes. Changing a constructor or changing the semantics of using a class can have a large effect on tests that have a lot of duplicated code. To understand why, let s begin with a simple example of a test, seen in listing 7.5.

public class LogAnalyzer { public bool IsValid(string fileName) { if (fileName.Length < 8) { return true; } return false; } } [TestFixture] public class LogAnalyzerTestsMaintainable { [Test] public void IsValid_LengthBiggerThan8_IsFalse() { LogAnalyzer logan = new LogAnalyzer(); bool valid = logan.IsValid("123456789"); Assert.IsFalse(valid); } }

The test at the bottom of listing 7.5 seems reasonable, until you introduce another test for the same class and end up with two tests, as in listing 7.6.

[Test] public void IsValid_LengthBiggerThan8_IsFalse() { LogAnalyzer logan = new LogAnalyzer(); bool valid = logan.IsValid("123456789"); Assert.IsFalse(valid); } [Test] public void IsValid_LengthSmallerThan8_IsTrue() { LogAnalyzer logan = new LogAnalyzer(); bool valid = logan.IsValid("1234567"); Assert.IsTrue(valid); }

What s wrong with the tests in listing 7.6 The main problem is that, if the way you use LogAnalyzer changes (its semantics), the tests will have to be maintained independently of each other, leading to more maintenance work. Listing 7.7 shows an example of such a change.

public class LogAnalyzer { private bool initialized=false; public bool IsValid(string fileName) { if(!initialized) { throw new NotInitializedException( "The analyzer.Initialize() method should be" + " called before any other operation!"); }

if (fileName.Length < 8) { return true; } return false; } public void Initialize() { //initialization logic here ... initialized=true; } }

Now, the two tests in listing 7.6 will both break because they both neglect to call Initialize() against the LogAnalyzer class. Because we have code duplication (both of the tests create the class within the test), we need to go into each one and change it to call Initialize(). We can refactor the tests to remove the duplication by creating the LogAnalyzer in a CreateDefaultAnalyzer() method that both tests can call. We could also push the creation and initialization up into a new setup method in our test class.

Listing 7.8 shows how you could refactor the tests into a more maintainable state by introducing a shared factory method that creates a default instance of LogAnalyzer. Assuming all the tests were written to use this factory method, we could then add a call to Initialize() within that factory method instead of changing all the tests to call Initialize().

[Test] public void IsValid_LengthBiggerThan8_IsFalse() { LogAnalyzer logan = GetNewAnalyzer(); bool valid = logan.IsValid("123456789"); Assert.IsFalse(valid); }

[Test] public void IsValid_LengthSmallerThan8_IsTrue() { LogAnalyzer logan = GetNewAnalyzer(); bool valid = logan.IsValid("1234567"); Assert.IsTrue(valid); } private LogAnalyzer GetNewAnalyzer() { LogAnalyzer analyzer = new LogAnalyzer(); analyzer.Initialize(); return analyzer; }

Removing duplication using [SetUp]

[SetUp] public void Setup() { logan=new LogAnalyzer(); logan.Initialize(); } private LogAnalyzer logan= null; [Test] public void IsValid_LengthBiggerThan8_IsFalse() { bool valid = logan.IsValid("123456789"); Assert.IsFalse(valid); } [Test] public void IsValid_LengthSmallerThan8_IsTrue() {

bool valid = logan.IsValid("1234567"); Assert.IsTrue(valid); }

In this case, we don t even need a line that creates the analyzer object in each test: a shared class instance is initialized before each test with a new instance of LogAnalyzer, and then Initialize() is called on that instance. But beware: using a setup method to remove duplication isn t always a good idea, as I explain in the next section.

The Setup() method is easy to use. In fact, it s almost too easy to use enough so that developers tend to use it for things it was not meant for, and tests become less readable and maintainable. Nevertheless, setup methods have several limitations, which you can get around using simple helper methods:

Setup methods can only help when you need to initialize things. Setup methods aren t always the best candidate for duplication removal. Removing duplication isn t always about creating and initializing new instances of objects. Sometimes it s about removing duplication in assertion logic, calling out code in a specific way. Setup methods can t have parameters or return values. Setup methods can t be used as factory methods that return values. They re run before the test executes, so they must be more generic in the way they work. Tests sometimes need to request specific things or call shared code with a parameter for the specific test (for example, retrieve an object and set its property to a specific value). Setup methods should only contain code that applies to all the tests in the current test class, or the method will be harder to read and understand.

Now that we know the basic limitations of setup methods, let s see how developers try to get around them in their quest to use setup methods no matter what, instead of using helper methods. Developers abuse setup methods in several ways: