How not to set up Tests

Some unit tests on a project were newly failing - I’d done the checkin immediately before the first failure, so it fell to me to sort out the problem.

Here is what I found … what do you see that’s wrong here?

[TestFixtureSetUp]
public void Setup()
{
    ...

    Thread.CurrentPrincipal 
        = new WindowsPrincipal(new WindowsIdentity("randomuser"));

    ConfigurationSettings.AppSettings["AzManStoreConnection"] 
        = @"msxml://c:\dev\randomproject\AzManStore.xml";
    ...
}

(Non-essential details obfuscated to protect the guilty)

I see two significant issues …

Firstly, the operation of the test is tightly coupled to the existance of the randomuser account in Active Directory. As soon as the account was disabled (becuase the developer had left), the test failed.

Secondly, the operation of the test is tightly coupled to the configuration file being present at the specified location. This not only prevented the build server from running the tests (as it checks out the project into a working directory named for a GUID), but it would fail if anyone ever checked-out the code somewhere other than C:\dev\randomproject!

The lesson to take away from this is simple, but profound: Minimize Coupling

Correct operation of a unit test shouldn’t depend on having the right Active Directory account (unless you’re testing Active Directory integration, of course), nor should it depend on having the code checked out into a particular working folder.