Good stuff. I especially appreciate the entreaty to limit assertions and corner cases to one test concern.
The only thing I didn't like was the Given When Then recommendation. BDD style story language is really meant for key specification examples, which can be automated in functional tests, but not really appropriate for unit testing.
I find adding bdd language comments in my unit tests to organize code makes them WAY more readable and I’ve gotten very positive feedback from coworkers about it.
I fucking love them, with a caveat. If they are written in such a way as to optimize readability, that’s when they really shine. The audience of these tests should be other humans, and they should be written in a way that makes it easy to read.
However, if they’re written in poor English they can muddle the intention and make it harder to read. They might actually make the tests even more confusing as you now have to figure out what the statements are trying to say. This is especially clear if you’re working with teams that don’t use English as their first language.
Despite that, I do think overall it’s awesome to use such tests in most cases.
This article says GWT, but all the examples are showing AAA (Arrange Act Assert). Subtle semantic difference, likely not the core of the article though.
I've found it just obscures what the test is doing. If I'm looking at a test that failed, I want to see the code that caused the failure, as plainly as possible; I'm quite capable of reading code (indeed I find code is better at communicating clearly than English is), so I'd rather see a minimum of ceremony than some misguided effort at making tests more readable for imaginary business users.
The only thing I didn't like was the Given When Then recommendation. BDD style story language is really meant for key specification examples, which can be automated in functional tests, but not really appropriate for unit testing.