TDD (Test Driven Development) - how to write good tests?

One of the bigger step in the developer's career is the moment when he starts to write tests. Of course he doesn't know how to do this and writes it wrong. Not every test is good for our system. When we start writing tests we want to test everything to provide 100% test coverage. The test report looks great, doesn't it? Unfortunately tests give us no information and are horrible to develop. Why our tests are so bad?

We write them after the code

When we do so we fit them to our code. So the tests say how code looks like instead of saying how it should look like. Writing tests before code has an important benefit. We use the code before we even write it so we know how it should look like to be simple and understandable. We only write enough code to make our tests satisfied. Less code means less bugs and less time to implement a functionality. If we can write a test for a functionality it means we understand what we want to implement. The main principle of the TDD is to write tests before the code.

We give them meaningless names

The tests should provide a knowledge about how the system works and how to use the components. The names should be clear. However, we often call them, for example "successTest". Even if we know exactly what it tests, it gives no information to a new developer in our team. We see this test but we do not know what functionalities the system has. Instead we can call it "it_should_register_an_user". This gives us a clear information what the class that we test should do. When we want to register an user somewhere in our system we can just check this test and we have a live example how to do this. Same thing with name "failureTest". It says nothing. Just name it "it_should_throw_an_exception_if_no_name_given". That says much more about how the system works.

We just do not use them

This is the biggest problem. We just write some tests and then forget about updating them. If they fail we often do not care about that. We just stop using them. Often we need to refactor code. We should update tests first so they reflect our business logic. Sometimes we forget about changing them. The best way is to run the tests after each commit to our project. It is a part of the process called Continuous Integration. Even then we should pay attention to whether the tests are done correctly and react if something fails. We should fix them as soon as possible.

We test everything

As I mentioned before this is not a good behavior to test everything in your code. You may think that such an approach is better because the system is better tested. So you test even getters and setter in case something changes. You end up with a million tests that say nothing. Tests should be simple and clear. Maintaining the tests should also be easy and not something that no one wants to do. More tests mean that they are harder to develop. The best way is to test the process or behavior and not to test every single class or method. This approach comes from BDD (Behaviour Driven Development). It gives a lot more information about the system and helps keeping our tests simple.