OK. You definitely heard of such a concept as Test Driven Development (TDD). When developers first discover all the delights of this approach – this is a transition to a new, better world, where there are less stress and insecurity. But realizing all the advantages of testing is not enough.

Conventional wisdom about unit tests is to ensure that they are intended primarily to improve the quality of your code. Another nice feature is their ability to painless refactoring, because tests will make sure that the original behavior is not changed.

The main argument against automated testing is more time spent on writing them. Indeed, automated testing does not replace other forms of testing.

Moreover some people use the following approach: “Write app and send it to testers (or even to the client directly). When errors are found – fix them and send back the corrected version, and so on. ” This approach may be justified in a situation of “do and forget it” – when you’ll never have to finish or reengineer your code. For some people it works, for other not.

It is difficult to argue with above arguments, but it’s not all (and from our point of view they are not principal). For us unit tests first of all are:

  • good design,
  • a good mood in the team,
  • the quality of work
  • another level of projects
  • ability to deal with interesting problems,
  • lack of large QA engineers team
  • tests are also the best specification

Good design has such wonderful features as poor connectivity, and a clear relationship between the classes and their objects. If writing a unit test is difficult, impossible, or it is too big and confusing – most probably it is not so much about the problems in the test, as in the design of the code itself.

I think you have noticed that after a certain stage of the project certain metrics goes down: you do not feel “drive” in work anymore, there are non-routine requests, something breaks all the time, etc. As the result it’s harder to meet a deadline, it reduce’s motivation and spoil’s the mood. Below you can find rough chart as we can see it:

It’s not cool! :( However, this can be avoided by start writing unit tests. As the result you get rid of fear to change something as well as monotonic regression testing.

Unit test – a useful source of specification (formal or informal), and not just a set of asserts. Often reading unit tests can help to understand the boundary conditions and business rules that apply to a class or subsystem. Very often documents becomes not valid at certain stage as their support takes huge amount of time, and honestly developers never read them! :)

We all know that happy and lovely development stage is much shorter than the depression, which begins with the maintenance. The fact that everyone knows about it, does not make the code easier to maintain.

Besides the fact that unit tests have a positive effect on the design and specifications, they also contains experience spent by the developer. Unit tests give a better understanding of what the programmer was thinking of, what boundary conditions he have checked or not. Plus, while unit test implementation the programmer dive deeper into the context of the problem, which may result in additional comments within the tests and code, and his efforts can be reused further.

In practice, customers often ask us these questions:

Q: Will TDD increase your productivity and development time?

A: It depends on the lifetime of your project. The more hours you plan to work on it, the better the case for tests. Generally, We’ve found that not writing tests almost always comes back and bites you in the butt.

During the first, say 200 hours of your project, you are creating code at about 50%-75% speed compared to someone not doing TDD. You don’t really need tests so much either, the codebase is still manageable. But once you start to pass 200 hours of development time, complexity begins to become an issue, you fix a thing here, it breaks there. You want to refactor messy code, but you decide against it because you fear breaking it, and problems start to pile on to eachother as time progresses. At 2000 hours, a project without a test suite is incredibly time-consuming to work in, especially if you’ve changed programmers. These are issues that are minimized to almost a non-issue when you are doing TDD.

Q: What minimum percent of code coverage is recommended in TDD projects?

A: You do not need to strive for 100% coverage. This requires too much effort to create such tests, and even more to support them. Average coverage ranges from 50 to 90%. Try to coverer all core business logic.

Q: Can you do TDD on a short timeline?

A: Short answer, not really, but it is useful to consider it even for small projects for the indirect benefits.

Q: Does test-driven development (TDD) really improve software quality?

A: Yes. TDD improves quality but takes longer. What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.

Q: Can you start using TDD after release and not before?

A: It will be difficult, because TDD imposes certain restrictions on the project architecture and code organization in general. From our experience, if the project did not mean writing unit tests from the beginning – start writing tests later on would be painful.

But that’s just our take on things, I’m pretty interested to hear what do you think. Don’t hold back.