Every it() block contains two parts: description and return call.
description: this is a description of the test case
return call: this block contains function(), it may also have a variable in it, basically this variable will have some set time for to set the total time for the it() block to get executed. You can use it without time as well.
There are many articles, tips and tricks available explaining the best practices and lessons learned.
And this is where I can see that in lots of cases when the description in the it() block starts with the word should.
These examples are being adapted by junior engineers, who don’t really know what or how should be done, because they are kindof lost, and they have the trust in the experienced ones, (they have even written an article about it), hence they are not questioning it. And in the end, they get use to it, and more and more projects end up with this symptom.
Let me have a question here.
Why does one feel the necessity of starting each description with should? Not with any other word that is available in the language, but with should?
Why do I have this question?
First of all, this can be considered as code repetition.
It doesn’t bring value, doesn’t contain information. It makes the description longer, you may even introduce line break, therefore it harms readability.
On the other hand, the word should suggests that the code writer is not confident in what the code actually does. For me, should implies the supposition that the code behaves in a way, in theory, but who knows actually what is going to happen in practice.
Who else should be more confident in the code’s behavior than the one who implemented that piece? So why not say this:
– Mmmm, let’s call the function with these parameters, and as a result, we get these.
Moreover, Jasmine assertions have the expect keyword. So you have expect statements in the block. When I read should in the description it gives a context in which expect is a bit weird.
So the code should work in a way, but we have expectations against it?
Besides test cases can be considered as part of the documentation. Keeping it as simple as possible makes easier to get information on the requirements within a blink of an eye when you revise the test suite.
The proposal I have here.
Start it() descriptions with a verb, not with “should”
How does it sound?