The tricky cases in testing - Resources

Test the writing of a file automatically

 

The test for writing proceeds as follows: In the test, a file is created by calling the method to be tested Write is generated. The file generated in this way is then compared with a file containing the expected content. The following listing shows the automated test.

using NUnit.Framework;

namespace resources.tests
{
    [TestFixture]
    public class FileAdapterWriteTests
    {
        private FileAdapter sut;
        [SetUp]
        public void Setup() {
            Directory.SetCurrentDirectory(
                TestContext.CurrentContext.TestDirectory);
            sut = new FileAdapter();
        }

        [Test]
        public void Write_a_file() {
            sut.Write("data.txt", new[] {"a", "b", "c"});
            FileAssert.AreEqual("testdaten\\writeTest.txt", "daten.txt");
        }
    }
}

In the test, calling up the Write method the file "data.txt" is generated. This is then compared with the file "testdaten\writeTest.txt". I perform the comparison of the file content with NUnits FileAssert through. Unfortunately, there is no counterpart to this functionality in MSTest. Another reason to switch away from MSTest.

Automated testing of integrated resource access

 

In the following example, I have combined the resource access with the processing of the read data in one method.

using System.Collections.Generic;
using System.IO;

namespace resources
{
    public class CsvReader
    {
        public IEnumerable Read(string filename) {
            var lines = File.ReadAllLines(filename);
            foreach (var line in lines) {
                var fields = line.Split(';');
                yield return fields;
            }
        }
    }
}

The Read method reads by means of File.ReadAllLines from a file and also processes the read content. So two aspects are mixed here.

To test this class, I created a file "testdata\somerecords.csv", which is accessed in the test. This is a Integration testbecause the two aspects Resource access and Editing the read data in the method Read and are also tested together in the following example.

using System.IO;
using System.Linq;
using NUnit.Framework;

namespace resources.tests
{
    [TestFixture]
    public class CsvReaderTests
    {
        [SetUp]
        public void Setup() {
            Directory.SetCurrentDirectory(TestContext.CurrentContext.TestDirectory);
        }

        [Test]
        public void CSV_Records_are_read_correctly() {
            var sut = new CsvReader();

            var records = sut.Read("testdaten\\somerecords.csv").ToArray();

            Assert.That(records[0], Is.EqualTo(
                new[] {"Title", "Price", "Author"}));
            Assert.That(records[1], Is.EqualTo(
                new[] {
                    "Working Effectively with Legacy Code",
                    "20", "Michael Feathers"}));
        }
    }
}

With mocks to unit tests

 

The logical part of the method Read cannot be tested in isolation with unit tests, as reading from the file is combined with the logic. It is therefore an integration test. Here again TypeMock isolator. With this powerful mock framework, the call of File.ReadAllLines can be influenced in the test. In the test, a lambda expression specified in the test method is executed instead of calling the .NET Framework method. This returns a predefined enumeration of strings so that the logic part of the method is tested with these strings as input.

[Test, Isolated]
public void Isolated_logic_test() {
    var sut = new CsvReader();
    Isolate
        .WhenCalled(() => File.ReadAllLines(""))
        .WillReturn(new[] { "a;b;c", "1;2;3" });

    var records = sut.Read("testdaten\\somerecords.csv").ToArray();

    Assert.That(records[0], Is.EqualTo(new[] { "a", "b", "c" }));
    Assert.That(records[1], Is.EqualTo(new[] { "1", "2", "3" }));
}

The use of TypeMock isolator or comparable tools should not be regarded as a free pass. Nevertheless, the principles of Clean Code Developer initiative. Although this tool can be used to create testability, it does not improve changeability one bit.

If, for example, the program is to be changed so that the data is no longer read from a file but retrieved from a web service instead, this is difficult to achieve in the structure shown. It would then make sense to first change the File.ReadAllLines call from the method before it is replaced by a web service call.

Conclusion

 

Despite powerful tools, there is no way around designing and adhering to principles. However, these serve to put legacy code under test and thus create the prerequisites for refactorings. Powerful tools are useful and fulfill their purpose. On the other hand, the handling and sensible use of the tool must be learned so as not to cause any damage.

What is your experience of using powerful mock frameworks in unit tests? Write a comment!