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.
