It is not enough for today’s software developers to know their programming language well. There are further skills, that more and more companies are expecting from there employees. One of the most important is Test Driven Development (TDD). This is not an introduction to TDD. If you want to learn it, I recommend Uncle Bob’s awesome Clean Code Videos (Episode 6 - TDD) or simply ask Google for it. But many developers are writing bad code and applying TDD does not make them writing good code. Instead it makes them also writing bad tests. So this is about writing better test code.
Applying simple rules
To understand why test code can be bad, you should understand, what it should do. It should work as the parachute, that keeps you alive, when refactoring your code. Tests may help you to be sure nothing breaks, when adding new features to your code. But tests may also work as sample code, that documents your APIs better than any other documentaion except the code itself.
But how can you make your tests better? It might help to follow some simple rules, that could be easily applied to every language or test style like BDD or Junit-style.
Tests should be a state machine
Many people do not like BDD at all, but there is a pretty nice idea in it - the given-when-then style some frameworks promote. This style forces you into a way of thinking about tests, that you should adapt. Even if you do not use a BDD framework.
Writing a test this way means there is a start state, something happens and than an end state is reached. If your test is broken, the state machine in it is broken. In BDD frameworks the first part of your test is the given block, where all the setup stuff is done. The second part is the when block, where an action is applied on the test object, created in the given block. At least you have a thenblock, where you assert, that the correct end state is reached.
It is very helpful to have this in mind while writing a new test. Keep these three parts seperated and do not mix them in some way. Do not write code in your test, where an if appears, or even more complex logic. In a test you should only do the above three steps. Do some simple setup, call a method on your test object or invoke the test function and assert the result is correct.
This might also make your code better. If you write messy code, tests written this way are harder to create and maintain. If you have to much of inheritance, dependencies on other objects or resources like IO, you will have to set it up in every test you write and that is no fun. But you should write your tests first and hopefully it makes writing messy code harder, if you have written a well structured tests first.
More on this great article can be read here.
Reacties
Een reactie posten