Back to the basics: Tests, part 2
As already said in the first part, tests are code, and be well written is essential to keep a good maintaining. And an important part of a well written test, it's your description about what the test propose. A good test descriptions and tests cases are highly util to identify bugs quickly and sometimes even to use as documentation how the code parts works and their goals.
To make simpler, let's get a pseudocode of a function that return true with a number is odd.
function isOdd numberToCheck:
if numberToCheck % 2 equal 0:
False
else:
True
There are a lot of ways to write a good test case, but here are some common examples that are the style that I have seen with more frequency into the code bases.
- Preposition style: "A number not divisible by 2 is odd"
This is interesting because allow us to explain easily the business logic for what the code does, allowing us to write a lot of different cases.
- Behavior style: "It should return true when passed the number 3"
I think this is the most common way, that is described in a more human style, to explain what the test does and what we expected that happens.
- "what is" style: "3 is an odd number"
This one for some people is considered an antipattern because it is not so flexible and descriptive, but is very common to see tests like that. Basically, say that the that does.
That is it, there are a lot of others styles and pros/cons of each one, the importance is to establish a convention and keep it in the team for everyone can easily identify what the tests are really testing.