Unit testing

If you're here, then your thinking about testing. Please visit my articles on SpecFlow for BDD to bring something new to testing.

There is lot to be said about unit testing (or testing via code), and a lot of opinions on the right and wrong way to do this. The first thing I say about code testing is that it doesn't matter how you do it or how much or how effective it is, we all need to start somewhere - just as long as you are doing some form of code testing it means your can build on it and address those areas where improvements can be made.

I follow three levels of code testing:

1. Unit testing (strict AAA)
2. Interaction testing (or integration testing)
3. System testing (as much as can be done)

Unit testing

AAA stands for Arrange (or assemble), Act (or action) and Assert.

• Arrange - arrange the information, mocks, stubs, objects needed to do the test.
• Act - action the functionality under test.
• Asset - test the expected behavior, result on interaction expected.

A few years ago I read and still reference the excellent book by Roy Osherove, the art of Unit Testing, this book and the associated videos on the website just linked corrected a few mistakes I had been making on what I though were my unit tests.

1. I was testing to much in each one of my so called unit tests, these I now classify as my Interaction or Integration tests - I still do them as they still add value.
2. I was writing all my own stubs and APIs.
3. I wasn't testing with trues mocks.
4. My tests were not named well.
5. My tests were only executed manually, when I or someone else felt like it.

All these points were corrected by Roy Osheroves' book and his excellent talks & presentations. I now use NSubstitute to perform by stub & APIs substitutions and for using true mocks. Note, there are many mocking and substitution frameworks including the new Fakes library built into MSTEST on Visual Studio 2012 (Premium or better), however I prefer to keep it simple, and NSubstitute is just that.

I'd been using continuous integration build servers for a while, and I'd not really embraced their importance in not only asserting that the code builds, but also that it passes the test. Configuring this into Cruise Control .Net was a bit more of a pain than I'd have liked, but since switching to Team Foundation Server/System its all plain sailing. Putting this in place promotes you running the test locally before check-in of your changes, no one wants to break the build.

For whats its worth, and because I'm testing the modification to my blogger template for showing code, below is a simple unit test using MSTEST and NSubstitute.

[TestMethod]
public void Calclate_DoesTheRightThing_ReturnsTrue()
{
    // Arrange
    IClassA sub = Substitute.For<IClassA>();
    sub.myProp = "10";
    sub.ReturnSomething( 9 ).Returns( 10 );
    ClassB underTest = new ClassB( sub );

    // Act
    bool result = underTest.Calculate("test", 9);

    // Assert
    sub.Received().DoSomething( 10, "test" );
    Assert.IsTrue(result);
}

Interaction & Integration testing

These are tests that are not focused on a single unit of functionality, but more on how the units of functionality interact and to check for correctness. These tests should also be able to be run automatically as part of the continuous integration build server, just like unit tests.

I'll followup in a later blog explaining why I think these should be part of your testing processes.

System testing

These tests that are focused on end to end testing in those cases that can be automated from code alone. There is a fine line between integration and system testing and it can be really blurred - again its not something to worry about, but remember the acronym DRY (don't repeat yourself), and in this case don't repeat your tests either, if you do it in one pace don't repeat the say test elsewhere.

The kind of testing here will likely require installs of your servers, real data bases, actual networks. Normally the environment is required to be manually configured/built prior to the running of these tests. If you have technically skilled test department they will be the ones producing a lot of the system test automation code.