It's also really tough for a non technical manager to assess a technical person, which makes sense. We have to different strengths and parts to play in the system, they can't be expected to do their role and keep up with technical skills (if they ever had them to begin with). It's a shame that we're often encouraged to become more managerial to get ahead or to get more responsibility/"power" (in the sense of saying what we think needs to get done, or who should get recognition).
I really wish more companies would stop seeing managers as being bosses. I don't know why a lot of places seem to think that dictatorships in the workplaces are the way to go. I've had so much success in places where my manager saw me (a technical lead) as an equal partner on a project, where both our opinions were weighted equally. I think it helped give those more introverted developers a voice. Since my responsibilty was the technical side I was really able to stay on top if their work and know what they were actually capable of. Some of my colleagues have had the same experience and it's really helped us from keeping introverted talented devs from falling through the cracks.
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 withtest_).So something like
test_clean_accounts__client_name_missing__fill_from_organisation_nameortest_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.todomarkers, 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 atodo(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).