1.5 KiB
| title | pubDate | permalink | tags | |
|---|---|---|---|---|
| Writing good automated test names | 2022-11-15 | daily/2022/11/15/writing-good-automated-test-names |
|
Something that I often see in code examples or tutorials are test methods like testGet or testAdd, or testSubtract. Short method names that don't describe the scenario that they're testing in much detail.
What if a get method returns different types of value based on the input or a string is passed into a calculator method like add or subtract?
I'd assume that the result of the calculation returns the total, but the test method doesn't say this.
I'd rather be overly descriptive and write methods like should_add_two_or_more_numbers_and_return_the_total() rather than testAdd. It's a lot more readable and easier to see what the intention of the test is, and it's much better to use longer descriptive names when using options like --testdox with PHPUnit, which converts the method name into a sentence, which is what I do when running tests in CI pipelines.
Something that I've picked up and recommend is to start each test case with the word "It" or "Should". This gives it a more behavioural feel and puts you in the mindset of what you're testing and not the methods that you're executing.
A method like 'testAdd' might make sense within a unit test focusing on a single class and method, but as I usually do outside-in testing - which mostly uses functional and integration tests - this approach works well for me.