merge-conflict:~/when-you-cant-use-tdd$

When you can't use TDD

I recently had a problem where I couldn’t use TDD. Since November, any C# I’ve written has been with TDD. So, what do you do when you can’t use TDD? I like TDD because I like that feedback loop around my design and around the outputs of my code. The aim is to get as close to that as possible, not to try and religiously follow the 3 laws of TDD at any cost.

The strategy:

  1. Create a boundary between everything that you can TDD, and the stuff you can’t. In my case, this meant creating an intermediate representation, a bit like how we create view models for our interfaces to keep any UI work as dumb as possible.
  2. TDD the parts you identified from earlier
  3. Write code for the parts you’re not sure how to test and try and write a test afterwards. Don’t write the entire system here; just enough functionality to start writing a test.
  4. You may find you’re now able to write tests first from now on depending on the result of 3.

My Experience

The above is for the general case, but here’s something more concrete based on what I experienced recently. The problem I had to deal with was generating a table inside of a PDF report. We decided to use a library that offered an API for creating all kinds of elements inside of PDF documents.

My first step was to look at our current representation and see how I could transform that into another representation that made it as easy as possible to use the API offered by the library. This part was easy to TDD once I had defined the output I wanted and thought about the API I wanted us to use to generate tables.

Now for the “hard” part. When I get stuck, I tend to think about the problem for a little bit and then give up and experiment with something. My goal was a workflow similar to how I do CSS on web pages; I always play with the CSS in inspect element so I can see exactly what’s happening and get immediate feedback. I wanted that with a PDF document. I had reasonable expectations around the PDF library’s API working; I can call methods to set the font size and add rows and columns etc. - but I wanted to see it. Every time I change something, I want to see what happens.

I ended up trying to use approval tests to get to the workflow I wanted. An approval test is slightly different from a ’normal’ unit test. With an approval test the first time you run it, you look at the result, and you either approve or reject it. Once a result is approved, that becomes the expected result. Alternatively, you can specify the expected result beforehand (not very feasible with a PDF file).

Using another package that adds some PDF enhancements (BetterPdfVerification - although this didn’t work with .NET Core, so I had to modify it first) and using BeyondCompare I was able to have the following workflow:

  1. Modify any of the code
  2. IDE (I use Rider) automatically runs the approval test anytime I save the code
  3. BeyondCompare would open up the PDF document and compare it to the last version. Whenever I made an update to the code BeyondCompare would also reload the view of the PDF. I keep the code open on one monitor and beyond compare open on the other.

Not only do I have a nice workflow set up, but when I’m all done, this test will run in the CI pipeline like any other and so we’ll be immediately aware if anyone changes the PDF report later by accident.

Here’s what an approval test looks like, taken from the BetterPdfVerification test suite:

[UseReporter(typeof(FileLauncherReporter), typeof(WinMergeReporter), typeof(ClipboardReporter))]
public class PdfVerificationTests
{
    [Fact]
    public void can_verify_pdfs_created_with_pdfsharp() {
        var pdf = createSamplePdf();
        PdfApprovals.Verify(pdf);
    }
}

Going back to the original problem; I’m now on step 4 where I can technically write the test first from now on. Although, I’m not specifying the output first - I’m always going to be approving or rejecting a result myself because it’s too difficult to validate the result directly via code. An approval test is more like a set of instructions about how to get the result rather than what the result will be - a test without the asserts.

I think the next steps with this are to extract/refine my PDF approval setup and release it as a Nuget package. The current BetterPdfVerification library doesn’t yet support .NET Core. My current setup is basically the BetterPdfVerification code with some parts of it ripped out and replaced with .NET Core compatible pieces of code.