Ask HN: Help me see why everyone seems to love TDD?

This is generally how I approach writing unit tests as well. Perhaps I'm doing TDD wrong, but I find myself running into the same problem as you that I often need to do too much design up front to write a test. The alternative is that I write the test using the simplest possible interface and then go back and continually change the test as I write the code. I've tried this but I haven't really found any benefit to this.

My approach is generally to write a passing test for a simple use case after I know that case is working. Then I'll write some tests for some more complex cases and fix any of those which fail.

I don't understand why people seem to think that testers could or should be replaced by automated tests. I've worked a lot with test automation, and I find it super important to have automated tests for any long-living project, but one of their main purposes are to off-load the manual testers from doing repetitive regression testing, and focus on more creative exploratory testing - things that humans (well, some) are good at, but computers are not.

In addition, testers should play a central role when it comes to validating requirements - they typically catch issues and inconsistencies that would otherwise go unnoticed until $x has already been spent on going down the wrong path.

In my (somewhat limited) experience, there's no such thing as writing code without testing it. The question is: are you testing this manually every time or are you automating it? I think that's a valuable way to phrase it to a non-technical manager, phrase in terms of limited situations:

A. I never test my code. When we go to ship the code, it breaks, and I have no idea where it's broken. So now I'm forced to take pieces out to see which piece is broken, then take functionality out of that piece until I find the piece that's broken. This is a process that actually takes longer than writing code, and it prevents me from working on new projects. If this is given to someone else, it will take them twice as long because they don't have the context of how the pieces work, and they'll wind up asking me about it anyways.

B. I never write tests for my code. After every piece I write, I test the project in entirety to see if that piece works and does what I want it to do. After the project is done, suppose we want to change that piece. Because there's nothing written that will test these pieces alone, someone now has to do work I've already done, which will keep them from working on something else.

C. I write tests before or as I write my code. I know when the pieces I write are done when they pass those tests. It takes around as long to write tests as to write code, so this process is faster. When we want to change a piece later on, we just change the tests to express the new desirable functionality, then rewrite the piece to pass those tests.

When I'm troubleshooting my code, I'm not adding value to the product or company. Therefore, the shortest amount of time spent troubleshooting is in turn the most profitable. C is clearly the shortest amount of time, because by writing tests I ideally spend no time troubleshooting. In reality, things will slip through the cracks, but those cracks are a lot smaller.

The problem is going to be that you have (almost definitely) built up quite a bit of technical debt. If you start testing now, you will start to expose the technical debt and take a productivity hit. Selling your boss on "TDD increases developer speed" is going to back fire.

I would try to sell them on more automated QA testing. That's a much easier sell, and the benefits should become obvious sooner (particularly when they can start firing QA testers and use that money to hire more automators).

Then you can start TDDing the QA testing. Map out the automated QA test for the feature in advance. Then developers can develop to the QA test, and will know when they have finished.

It's a long process, but turning around the short-termist mentality takes a long time.

> TDD is a bit like waterfall, in the sense that you're assuming you know what the code needs to do before you write it

Very true; but there are cases where you actually have that knowledge. If you are asked to port some application to another framework or language, and have tests, I'd highly recommend you use them.

I have been refactoring an ETL pipeline (to offer extensible, more flexible behavior) that sort of grew out of interns applying ad hoc transient business rules. No tests were present but I had a quite large coverage over past inputs that were yielding a correct output. I'd say code size shrank about 70%.