Programming

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).