Be a Developer, not a Blender

It does not matter if you have a huge amount of tests without quality

I have seen developers saying that their project has more than 300 tests, but each new version creates a lot of new bugs or some old bugs start happening again.

Take a look at the code below:

if (value != null) {
    // do something
} else {
    // do something else
}

What is the point in writing 30 tests that get in the value != null statement and the else condition has no tests?

You need to test all business rules, make sure that all rules are covered.

A developer will have a hard time explaining why he expend a lot of time writing tests, but the functionality is with a lot of bugs. There is no reason to “re-test” the same “if” hundred of times if the new value used in the tests do not generate a new behavior; the incorrect test starts to be written when the developer stop thinking about: “what to test”. Always remember: “a bug might be hidden in the else”.

Use Test Tools

Use some test tools that will you help you in the tests. I could mention here:

  • Mock – Create objects that will behave in the way that you want, e.g.: webservice or a database action. Some frameworks are: PowerMock, Mockito, Easymock, Aquiles, SpringTest (it is possible to mock requests HTTP)
  • Coverage of tests – frameworks that will indicate which lines are tested: Cobertura, Jacoco, Emma
  • Static code analysis – Frameworks that search for bugs or optimization: Checkstyle, FindBug, PMD
  • Automated tests – You can schedule a framework to trigger the tests after a commit. This framework will check if there is a new commit and execute the tests: Jenkins and Bamboo

There are other tests frameworks, but I did forgot their names. =(

Did you find a bug? Create a test for it

This is an easy to do task that should be done for every developer when a bug is found. It is easy to solve a simple bug, but it is easier to bring it back to the project after the bug has been fixed.

If you found a bug you should create a test that reproduces the problem and correct it later. Put in its name or in a comment the ISSUE/TASK (e.g. Jira) about the bug. With this ISSUE/TASK in the code is easier to track the reason and the solution if someday it happens again for some code update or environment change.

Conclusion

Be sure that your code is covered by the tests and that the business rules are always tested.

2 thoughts on “Be a Developer, not a Blender

Leave a Reply to uaihebert Cancel reply