We use something similar where I work. Not having a clear seperation between the parts of the name feels a bit noisy and hard to parse, so we use: test_<function>__<context>[__<result>] (pytest, Python, looks for functions starting with test_).

So something like test_clean_accounts__client_name_missing__fill_from_organisation_name or test_open_chest__unlocked_and_has_items__items_collected.

The double underscores make the linter unhappy, so that check is disabled for test names. It’s helped guide how people with how they write their tests, shifting towards more BDD type testing, as the article points out as well it’s also kept tests smaller and focused, and made our codebases more self documented. No one enjoyed adding docstrings and this seems to have encouraged slightly for TDD style work (we don’t necessarily push TDD but there are use cases where it just makes sense, yet developers were avoiding it). It was a small changed that upped the general quality of tests and code, leaning into developer laziness rather than trying to fight against it.

It’s also been useful for working with more junior engineers. On established projects they can just read through the tests. On newer projects we might pair code a wireframe of the program, get some test names written down, wrap them with @pytest.mark.todo markers, and let them have at it. The todo markers mean they can go more at their own pace without it feeling overwhelming with fails. We also sometimes do this when a bug, enhancement, or feature request comes in, we just create the test with the name then add a todo (feature, bug, …) so it doesn’t break the flow, but is documented, and someone can pick it up later (people weren’t always recording these in tickets… So it’s an improvement).

Best Practices thinking considered harmful. 🤷

I like test names that are full sentences. Doing this for its own sake is unnecessary. It’s probably wise to practise this for a year, then decide when you still need it.

For me, quite often, a combination of the test group name (often naming a behavior) and test function name (often naming a special case of that behavior) suffices, even though it is not a full sentence. (Example: test class SellOneItem, test method productNotFound. Is this not clear enough?)

Test function names that merely repeatedly duplicate details (“conversion should…” to start 12 test names) indicate a test group trying to emerge (“Conversion Tests”). Insisting on full sentences for its own sake often either masks this risk (and delays helpful refactoring) or represents redundancy (merely reiterating what has been helpfully refactored).

I have found this attention to full sentence names most helpful for tests whose audience is not programmers, since those folks are not accustomed to common source code conventions and patterns. For Programmer Tests, I think “should” turns this helpful advice into a risky overstatement.

Almost always use parameterized style tests, always have a name field, I don’t use full sentences tho, that seems like too much. Don’t believe I’ve ever seen a test like that either

These toy examples feel like strawmen to me