What does your naming convention for tests/checks look like?

[simon_tomes]

This post by @mkutz is brilliant, helpful and thought-provoking. How to Name Tests for Maintainability | by Michael Kutz | Feb, 2023 | Medium

I’ve lost count of how many times I’ve had this debate with various team members. “Describe the test even if the name is ridiculously long”. Or “Let’s keep it short and to the point”. Or “Blah blah blah we should name it like this.” It’s a tricky one!

Here’s my take on Michael’s approach:

Understand context, apply rules and that’s the naming convention to use

How about you? What’s your approach to naming tests/checks?

[adrianjr (Adrian)]

I name my tests so that they describe at a high level the feature space/bug they are covering. It’s helped in the past when I’ve been asked “do we have any tests that cover x feature?”, I can easily run a search and find them.

[petalmd (David-Alexandre Bélair Paulo)]

Not only tests should be named to describe. I also try to make the test data to be self explanatory to help anybody who as do deal with it in the future.

For example for a test used to transfer a task from a user calendar to another.
User A : Firstname= “Transfer”, Lastname= “Initiator”
User B : Firstname= “Transfer”, Lastname= “Receiver”
User C : Firstname= “Transfer”, Lastname= “Approver”

The task could be named : “Transfer with approval test task”
With a description that goes like this
“Task used for the task transfer test (TESTID-XXXX). Configuration: Option A=true / Option B=False / Option C=False / ApprobationNeeded=True”

I even find myself happy about having this info when a revisit after a while

[kinofrost (Chris)]

I like many of the points raised in the original so I’ll take a slightly different perspective to provide some novelty.

Each name is a lie. A trap laid in a tacit conspiracy of silence.

Consider the limitations of your tools, consider your context, consider your needs. The name is a communication tool, so consider your audience, their context and their needs.

Then lie in a way that balances utility with risk.

If I were to suggest possible changes to check suites I rarely see I’d say use whatever names but include a review date and a purpose where possible. The check needs to prove why it deserves the cost of its existence in a changing context, and expose its own lies and lazy shortcuts, and that will make it far more maintainable and provide understanding about its attempt at coverage to different audiences, even after whoever wrote it left and the new person tries to clean it up. My biggest question when looking at check code is “what were you trying to achieve here?”, especially when I’m justifying that coverage against regression suites or other testing elsewhere. It’s all part of a bigger concept of coverage, and making that information available in a usable way to other testers pays respect to them, their work and the craft of testing.

But it depends on so much context, so again - consider limitations/context/needs for you and your audience and you shouldn’t lie too dangerously.