2

Online resources that discuss testing recommend the following pattern when writing your unit test method names:

given[ExplainYourInput]When[WhatIsDone]Then[ExpectedResult]()

This makes developers write extremely long test method names.. and this is somehow the acceptable standard? There must be something better.. I think I've seen annotations being used instead of this.

Comments
  • 0
    Long method names are not something I personally like to see, I tend to abbreviate the shit out of them. However, when it comes to method names for tests, more is more so you know what the heck is being tested. Plus, I like the way F# lets you write an otherwise illegal method name with spaces and all using:

    ``given [explain your input] when [what is done] then [expected result]`` () = ...

    Makes for extremely readable output on your test results.
  • 1
    @SomeNone do the other programmers understand your abbreviations without having to think twice? Are the abbreviations consistent over the whole Code base?
  • 0
    That is why you have comments!
  • 1
    We all know a test method includes all those parts. Why repeat those given/when/then?

    Omit them and separate those parts with underscores. That's quite a common practice I've seen many times

    e.G. I use: swapNumbers_includesNull_throwsIllegalArgExc()

    these are longer method names than usual but YOU don't call them. You just see them in the test report. And when you test the same swapNumbers with different WHEN part, the report looks real nice
  • 0
    @netikras Nice, I'll see about implementing that. Thanks.
Add Comment