Back to the basics: Tests, part 5

There are a lot of options to organize our test, but let be aware in some details to no fell in some common traps.

  • One test, a lot of cases: The hurts the one of the most important programming principle that is separation of responsibilities, remember one test, one case, try to create a single test that assert a lot of different case is awful. You lose the big part of the benefits of tests.
  • Tests without assertions: Well, stranger but is very commons into a bad developer to hack the tools that verify code coverage, I will not say anything because, if a test does not have any assertion, do not test anything, so is same thing of nothing.
  • Lack of Isolation: We see a lot of strategies to cover the real world, but if something is not properly configured, some lacks can happen and your test maybe is actually making an external request or create something at the database, this is really dangerous.
  • Coupling between tests: Imagine that you will test a repository and the first test insert something and the second test verify if a get works, you are creating a coupling between the tests, the second only will work if the first run successfully, this hurts directly good tests practices.
  • Overuse of Mocks and Stubs: As these strategies you can define returns, when they have some abuse in their usages, your tests are a lie! Because, if you need to verify is a functions returns "X" but you have an explicit stub forcing the "X" as returns, you are testing your own stub, not the code.
  • The DRY principle: In tests, the good is had the independence of each one and all of them have explicit what they have and use, so DRY is nice to avoid, you can use the hooks, but is a good practice to new overuse them.
  • Fragile Tests: The tests must bring security about the functionalities implemented, do not make any sense to create a test to validate the Date.now() for example, where your tests only pass if run 5 p.m. for example.
  • Slow Tests: Tests with the time, the idea is to increase more and more, if your tests are slow to run, all your development flow will start to suffer this consequence, so it is primordial, always to check the test velocity to guarantee optimization.

And remember, tests are also code, so treat them equal!