On TDD.

Intro

Test Driven Development, or TDD, came up as part of Extreme Programming (XP) around the year 2000. The idea behind TDD is simple: first, you write a test. Then, you write the code to make that test pass. This process is sometimes followed very strictly by developers.

But is TDD essential? Is it useful? And should your engineers do it?

My Take

I believe tests are super important. They help ensure that your code works as expected.

However, at the beginning of creating a new feature, I often don’t know how the final architecture will look. Writing a test at this early stage would only be possible at a very high level. This often leads to tests that are not optimal. They might be too slow and use tools like Selenium, or be they are too unspecific when bugs occur.

Writing tests first is neither essential for me - nor do I see any benefit during regular software development in my case.

Is TDD bad?

If you like TDD, then go ahead and use it. There is nothing wrong with following this method if it matches your style of working. It can be a great way to ensure your code is reliable and maintainable.

I personally don’t use it often. I first write my code, then tests, then code, then tests and refine along the way. Religiously following tests and then code does not match my style of working.

When TDD Is Essential

There are times when I find TDD - and writing first the test - then the implementation - to be essential.

And this is the case when I encounter a bug. I first write a test to reproduce the bug. Only after I have a test that reproduces the bug do I move on to fixing it. This approach ensures that the bug will never happen again because the test will catch it if it does.

TDD is perfect for writing regression tests.

Conclusion

Tests are essential, but writing tests first is not essential in my opinion. I only write tests first in case of bugs. In regular software development I rarely do it - and I also don’t care much. YMMV.