Test Naming [Automated Testing Series]

For the last 6 months I’ve been thinking and reading¬†a lot¬†about how best to write automated tests for applications – including data generation, structure, naming, etc. This blog series is a foray into my current thinking (which will probably change over time; for instance I’m looking back at tests I wrote 6 months ago that I thought were awesome and now thinking that I hate them :P). I’m inviting you to join me on this journey by publishing this series and I encourage thoughtful comments to provoke further thinking and discussion.

Test Naming

I have always been a fan of the Arrange Act Assert structure within a test and started by naming my test classes like <ThingBeingTested>Should with each test method named like A_statement_indicating_what_the_thing_being_tested_should_do. You can see examples of this type of approach in some of my older repositories such as TestStack.FluentMVCTesting.

More recently I’ve started naming my tests with a Given, When, Then description (be it an acceptance test or a unit test). I like the Given, When, Then method naming because:

  • Generally the Given will map directly to the Arrange, The When will map directly to the Act and the Then will map directly to the Assert – this provides a way of quickly cross checking that a test does what the name suggests it should by comparing the name to the implementation
    • I find this really useful when¬†reviewing pull requests¬†to quickly understand that the author of a test didn’t make a mistake and structured their test correctly
    • e.g. it’s probably wrong if there is a Given in the name, but no clear Arrange section
  • It requires that you put more thought into the test name, which forces you to start by thinking about¬†what¬†scenario you are trying to test rather than “phoning in” an¬†arbitrary¬†test name and diving into the implementation and focussing on¬†how¬†you are testing it
    • My gut feel along with anecdotal evidence from the last few projects I’ve worked on – with developers of varying skill levels – suggests this leads to better written, more understandable tests
    • Side note:¬†I really like the idea discussed by¬†Grzegorz GaŇāńôzowski¬†in his¬†TDD e-book¬†about the order in which you should write a TDD test (from the section “Start From The End”) – he suggests you start with the Then section and then work backwards from there
      • I can’t honestly say I usually do this though, but rather just that it sounds like a good idea; generally I know exactly what I want to write when writing a test (yes, it’s possible I’m just naive and/or arrogant ;))

To clarify, I still use Arrange, Act, Assert in my tests. I could write a whole blog post on how I structure the AAA sections in my tests, but luckily I don’t have to because¬†Mark Seemann has already written a really good post that mimics my thoughts exactly.

10 Replies to “Test Naming [Automated Testing Series]”

    1. Cool. I like that.

      When I finish the next post in the series I’ll be covering something that is similar, but that is still a little different in intent so is a handy link.

      Thanks mate

  1. Hi Robert,

    Thanks for commenting on the chapter about starting from the test! I appreciate your opinion!

    I agree that starting backwards is a little less practiced technique from among those I described, especially among the fluent TDD practitioners. I often use it though when I show TDD to someone else who is not familiar with it. This is because people are having a hard time starting from test and thinking about the end result is sometimes easier than declaring an object and all its collaborators upfront. This is especially true when using mocks – novices often don’t know what to mock, what not, but it’s fairly straightforward to say “ok, let’s say I want the alarm triggered…” and work from that.

    When starting from test, it’s always easier to go from “knowns” to “unknowns”. So when I already have an object and I know what method is yet to be implemented, I often start from that and then wonder “so what is really expected by someone who invokes this method?”. When the API is not yet known, concentrating on end result lets me play around with shaping the API, while still concentrated on the end result (this is especially true with few initial tests in a codebase).

    Another thing I appreciate is that it often produces more readable variable names. When my assertion goes last, I often have the temptation to write:

    Assert.Equal(0, result);

    while when starting from assertion (or mock verification), I tend to name the result variable(s) better, e.g.

    Assert.Equal(0, arrayElementCount);

    Anyway, “starting from the end” is just one of the techniques. In my opinion, It’s useful to familiarize with them all and pick one that best suits current situation or your flow of thinking in a given moment.

    P.S. Just want to mention that I don’t claim any credit for inventing this technique – I got it from Kent Beck’s book :-).

    1. Hi Grzegorz,

      Thanks for the great comment! I completely agree with everything you said. As I hinted in the post – I think it’s a really great technique that I’m sure I would find useful in some scenarios where I don’t have a clue what I’m testing and certainly is a useful technique for people getting started.

Leave a Reply

Your email address will not be published. Required fields are marked *