If you come from writing unit tests after the fact, you might struggle when writing your tests first. A test written after the fact and via TDD don’t have to differ at all. How you write the test will differ significantly.

Everyone does this slightly differently by the way, but here’s how I (mostly) do it.

[Fact]
public void test() {

}

1. Sometimes I can’t think of a name straight away, sometimes I can - if I can’t then I name it something stupid. At this point I don’t care.

[Fact] 
public void test() { 
  var result = calculator.Add(5,6); 
}

2. Now I do my act part of the test. This is where I’m thinking heavily about the API I want to interact with. In this case it’s simple and I can throw the inputs straight in.

If the arguments to the method were complex objects then it’d be different. If they’re new types that I’m creating right now then I’ll create an empty class with the name I want and that’s it - then I’ll initialise one of those objects as a parameter with the default constructor.

If my argument is of a type that already exists and it’s got some constructor that forces me to give it a few things then I can either throw nulls in and handle that case first or do some arranging.

My preference is always act, assert then arrange. But sometimes I do resort to act, arrange then assert. There is no ‘right’ way here - do whatever is easiest for you.

[Fact]
public void test() {
  var result = calculator.Add(5,6);
  result.Should().Be(11);
}

1. Now I write my assert. Oh no it doesn’t compile (red).

[Fact] 
public void test() { 
  var calculator = new Calculator();
  var result = calculator.Add(5,6);
  result.Should().Be(11);
}

2. I do the required setup and run the test, it fails - awesome. Then I go off an implement it until it’s green.

[Fact] 
public void Should_GetTotal_When2NumbersAddedTogether() { 
  var input1 = 5; 
  var input2 = 6; 
  var expected = 11; 
  var calculator = new Calculator();

  var result = calculator.Add(input1,input2);
  result.Should().Be(expected);
}

3. Can I make this test better? Sure I can - I split out the data into variables so I can then add them as arguments to the test so I can be extra sure my code works by having 2 sets of test data.

Oh yeah, I give it a proper name too!

[Theory]
[InlineData(5, 6, 11)]
[InlineData(2, 2, 4)]
public void Should_GetTotal_When2NumbersAddedTogether(int input1, int input2, int expected) {    
    var calculator = new Calculator();
    var result = calculator.Add(input1,input2);
    result.Should().Be(expected);
}

And there we are.

When learning to write unit tests, it makes sense that people learn to write tests in the arrange/act/assert order, but for TDD, it doesn’t fit as well. You can do it, but you have to think upfront more. In this silly example, you could quickly think of it all upfront, with some proper code? Hmm, I would struggle.

Unfortunately, some coding standards dictate that you must comment the arrange/act/assert blocks in every single test. That is torture. I don’t open a project with hundreds of tests in it and think “thank god these developers put arrange/act/assert comments in - I’d be lost without them!” Having to add those comment blocks in after I’ve written a test would really turn me off testing.

We developers know the meanings of all sorts of acronyms: HTTP, API, SQL, REST, SOAP, TCP, UDP, HTML, CSS - but we’re at risk of forgetting how to structure a test unless we add arrange/act/assert comment regions on all of our tests!?!?! Sigh.

If a test needs arrange/act/assert comments to be readable - the test isn’t good enough.