One of the most common examples of where we can drop an imperative verb prefix on a method name is in testing.
Unless a framework — such as pytest — requires 'test', such a prefix serves no useful purpose. It qualifies as a noise word, simply repeated what we already know from annotations/attributes, context, etc.
Stepping away from the imperative mood frees up the name (and the developer) to focus on naming a test more in terms of intent and purpose than as a directed action.
There are a number of popular naming styles that, for all their variation, often lead to names that contain the same information.
For example, the propositional style that I advocate (describe a property or behaviour using an indicative sentence), the BDD 'should' style, the more emphatic 'must' style, Roy Osherove's style (UnitOfWork_CallContext_Result), the long form Given-When-Then style, etc.
One thing they all share is fully informing the reader of what they can expect.
Whatever style you prefer, a useful guideline is to ensure that the name includes the form (but not necessarily the humour) of a joke: it should have a set-up and a punchline. Many test names have either a set-up (they tell you what is being tested and in what situation) or a punchline (they focus on outcome), but miss the other part (you don't know what outcome you're expecting or what leads to an outcome).
Test names? They're a joke 🙃
@kevlin with functional frameworks like Jest and Pest, I like using `describe` blocks to explain the conditions, and `it` to declare the outcome.
The test name is output to the console like:
given condition x > when event y > should do z
@paulshryock Yes, that works well when the shape of the code aligns well with grouping them like that, but can fragment when the outcome or the action offers a better grouping.
In those cases, I would favour using 'describe' for the outcome (the 'then') or action (the 'when'). For this reason I prefer 'test' over 'it'.
Kevlin Henney
Paul Shryock