Unit tests are part of the job that developers do while building software. Some developers might not write unit tests. But, IMO, majority does. If you are one of those, how do you treat the unit test code comparing to the production code?

1. Do you think about maintainability?
2. Will you refactor the test to make it better? Note: I use the term refactoring from the Refactoring book by Martin Fowler.
3. Have you used the advantages that the test framework offer?

To be honest, I had not thought about that much. In the beginning of my career, I wrote tests that followed the current structure of the projects. I did not question that much. Over the time, I started to feel the pain so I made changes Unit Test from Pain to Joy which has served me well in that project.

Write Tests

Recently, I have had a chance to work on another project. I was tasked with writing unit tests (and integration tests) to get used to the system and to be able to run tests with multiple credentials, AKA login user.

Here is the test, not a real one of course. But the idea is the same. I want to run the test with different credentials. The username and password must be passed to the parameters. This is very useful when you look at a test report. By parameterizing the report will show values passed to the test.

[TestFixture]
internal class MultiCredentialsTest
{
    [Test]
    [TestCase("read_user", "P@ssword")]
    [TestCase("write_user", "P@ssword")]
    public void RunWithDifferentCredentials(string username, string password)
    {
        // The test body goes here.
    }
}

And there will be many of them. It worked as expected. But there are potential problems. Can you guess the problem?

1. What happens when one of test users is changed either username or password?
2. What if we want to add more test users into the test suites?

Think about the situation where there are hundreds even thousands of them. It will be a pain. I need a solution to centralize the test data. My process has started.

Make Them Better – Manageable

It was time to look at what NUnit offers. NUnit has supported TestCaseSource. You should check it out first if you have not known it. In the nutshell, it allows developers to centralize test data in a manageable manner. That was exactly what I was looking for.

I created a TestCredentialsSource to produce the same test data. I would prefer the name TestCredentialsFactory, but seems the "source" fits better in the unit test context.

internal class TestCredentialsSource
{
    public static  IEnumerable<object> ReadWriteUsers = new IEnumerable<object>{
        new object[]{"read_user", "P@ssword"},
        new object[]{"write_user", "P@ssword"}
    }
}

The test was rewritten with version V1. There are 2 versions for comparison.

[TestFixture]
internal class MultiCredentialsTest
{
    [Test]
    [TestCase("read_user", "P@ssword")]
    [TestCase("write_user", "P@ssword")]
    public void RunWithDifferentCredentials(string username, string password)
    {
        // The test body goes here.
    }

    [Test]
    [TestCaseSource(typeof(TestCredentialsSource), "ReadWriteUsers")]
    public void RunWithDifferentCredentials_V1(string username, string password)
    {
        // The test body goes here.
    }
}

In the test, I did not have to deal with test values. The test data was encapsulated in the TestCredentialsSource with the ReadWriteUsers static field.

Make Them Even Better – Reuse and Duplication

It was good with known specific set of users. There were certain tests that want to run with a specific user. It should be fairly easy with another property in the TestCredentialsSource

internal class TestCredentialsSource
{
    public static  IEnumerable<object> ReadWriteUsers = new IEnumerable<object>{
        new object[]{"read_user", "P@ssword"},
        new object[]{"write_user", "P@ssword"}
    }

    public static   IEnumerable<object> SpecificUser = new IEnumerable<object>{
        new object[] {"special_user", "P@ss12345"}
    }
}

What if I wanted to test with only "read_user"? What if I wanted to combine the "read_user" with "special_user" for another test? One option was to define them in the TestCredentialsSource. Which was still fine because it was still manageable in a single file. But it was awkward.

Was there any better alternative?

Yes, there was. Let’s encapsulate the data in a class. Welcome to TestCredentials class.

internal class TestCredentials
{
    public string Username { get; }
    public string Password { get; }
    public TestCredentials(string username, string password)
    {
        Username = username;
        Password = password;
    }
    ///<summary>
    /// Convert the object into an array of properties object which can be used by the TestDataSource
    ///</summary>
    public object[] ToTestSource() => new object[] { Username, Password };

    public static TestCredentials ReadUser = new TestCredentials("read_user", "P@ssword");
    public static TestCredentials WriteUser = new TestCredentials("write_user", "P@ssword");
    public static TestCredentials SpecialUser = new TestCredentials("special_user", "P@ss12345");
}

The class supplied 3 factory methods to construct the needed credentials. This was the only single place where the data was provided without any duplication.
The TestCredentialsSource became much cleaner

internal class TestCredentialsSource
{
    public static  IEnumerable<object> ReadWriteUsers = new IEnumerable<object>{
        TestCredentials.ReadUser.ToTestSource(),
        TestCredentials.WriteUser.ToTestSource()
    }

    public static   IEnumerable<object> SpecificUser = new IEnumerable<object>{
        TestCredentials.SpecialUser.ToTestSource()
    }
}

Cool! The data has gone from the source definition. But there was still one thing that I did not like much – the setup of "SpecificUser" in the TestCredentialsSource. Having a source for a single value did not sound right to me.

There was a solution – convert the TestCredentials to a source that NUnit can understand. Implement the IEnumerable. TestCaseData is defined by the NUnit framework

internal class TestCredentials : IEnumerable<TestCaseData>
{
    public string Username { get; }
    public string Password { get; }
    public TestCredentials(string username, string password)
    {
        Username = username;
        Password = password;
    }
    ///<summary>
    /// Convert the object into an array of properties object which can be used by the TestDataSource
    ///</summary>
    public object[] ToTestSource() => new object[] { Username, Password };

    public static TestCredentials ReadUser = new TestCredentials("read_user", "P@ssword");
    public static TestCredentials WriteUser = new TestCredentials("write_user", "P@ssword");
    public static TestCredentials SpecialUser = new TestCredentials("special_user", "P@ss12345");

    public IEnumerator<TestCaseData> GetEnumerator()
    {
        return new List<TestCaseData>
            {
                new TestCaseData(Username, Password)
            }.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

With the in place, I could write the 2 below tests. There was no limitation of what combinations I could make of test credentials.

[Test]
[TestCaseSource(typeof(TestCredentials), "SpecialUser")]
public void RunWithDifferentCredentials_SpecialUser(string username, string password)
{
    // The test body goes here.
}

[Test]
[TestCaseSource(typeof(TestCredentials), "SpecialUser")]
[TestCaseSource(typeof(TestCredentials), "WriteUser")]
public void RunWithDifferentCredentials_CombinedUsers(string username, string password)
{
    // The test body goes here.
}

The End

The good result does not come by accident. I could have stopped at any step in the process. By pushing a little bit further, by asking the right questions, the end result was more than I had expected.
If you are writing tests code, should you look at them again and ask questions? Give it a try and see how far it takes you.

Unit Test is an art. There is no silver bullet for what to test, how to test, what tools to use. In my opinion, everything depends on the kind of projects, the maturity of the projects, and the skill of developers in the projects.

The Story

Given this piece of code. It is not a real production code nor production quality code. I made it up to demonstrate in this post.

    public class Account
    {
        public virtual bool IsClosed { get; set; }
        public virtual decimal Amount { get; set; }
        public virtual void Withdraw(decimal? amount)
        {
            Amount -= amount.Value;
        }
    }

    public class AccountManager
    {
        private readonly Account _account;

        public AccountManager(Account account)
        {
            _account = account;
        }

        public void Withdraw(decimal? amount)
        {
            if (_account.IsClosed)
                return;
            if (amount == null)
                throw new ArgumentNullException(nameof(amount));
            _account.Withdraw(amount);
        }
    }

This is not a design or best practice post. Let’s focus on the business logic and what/how to test.

There is an Account with 2 properties:

1. IsClosed (true/false): If closed, cannot withdraw money.
2. Amount (decimal): The current total amount left in the bank Account. The amount is reduced by the Withdraw method.

I keep the Account class pretty simple.

To manage an account, we have AccountManager. What it does are

1. If the account is closed, nothing happens.
2. If not closed, and the amount is null (to demonstrate the point that it is invalid withdrawn amount), throw ArgumentNullException.
3. If all is valid, the account’s amount is reduced by the withdrawn amount.

How are we going to test that 3 expected behaviors?

The Analysis

I believe at this phase, we have to depend on the mind of the developer. First, we need to recognize what kind of test we should perform.

#1: Look like an interaction test. We want to verify a certain behavior: Nothing happens.

#2: Verify input valid which expects an exception to be thrown.

#3: Look like a state test. We want to verify the account’s state. Why? Because we do not really care how the money is withdrawn. We only care about the amount left.

The Technology

Let bring in the tools we know to test. At this phase, depend on organizations; size and kind of projects. I work on .NET stack. I will use MS Test + RhinoMock (for interaction test).

#1: When the account is closed, nothing happens.

The account class might have many properties (now or later), but I only care about “IsClosed” property.

    [TestClass]
    public class AccountManagerTest
    {
        [TestMethod]
        public void Withdraw_AccountClosed_DoNothing()
        {
            // Arrange
            var account = MockRepository.GenerateMock<Account>();
            account.Expect(x => x.IsClosed)
                .Return(true);
            account.Expect(x => x.Withdraw(Arg<decimal?>.Is.Anything))
                .Repeat.Never();
            var sut = new AccountManager(account);
            // Act
            sut.Withdraw(null);
            // Assert
            account.VerifyAllExpectations();
        }
    }

The main point is at the “Arrange” phase. I expect these behaviors

1. The “IsClosed” must be called
2. The “Withdraw” must not be called. It means: Do nothing.

I am happy to see that test passed.

#2: Throw ArgumentNullException

        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void Withdraw_AccountNotClosedAndAmountNull_ThrowArgumentException()
        {
            // Arrange
            var account = new Account {IsClosed = false};
            var sut = new AccountManager(account);
            // Act
            sut.Withdraw(null);
            // Assert
        }

I can use either Mock or real object at this test as far as ensuring the IsClosed is false.

#3: If all is valid, account’s amount is reduced by the withdrawn amount

        [TestMethod]
        public void Withdraw_AllValid_AmountReducedByWithdrawnAmount()
        {
            // Arrange
            var account = new Account
            {
                IsClosed = false,
                Amount = 100
            };
            var sut = new AccountManager(account);
            // Act
            sut.Withdraw(30);
            // Assert
            Assert.AreEqual(70, account.Amount);
        }

At this test, I do not care how the system implemented. Given a valid account, and a valid amount to withdraw, my account must have the right amount left.

Be very careful, fellows. If you use mock here, you will end up with interaction test.

As I said in the beginning, unit test is an art. You have to research, learn about it every day. Watch other people do it. Make up your own mind. During my career, I found out that developers have a tendency to jump directly to “The Technologies” phase. “The Analysis” phase is very important.

Happy coding and write more unit test.