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