Ask HN: Seriously, how do you TDD?

"The said we had a new client, they had a weird name."

This is the material piece of information which lead to the fix. Your TDD simply made it faster to locate the offending line.

Seems like a really poor justification for TDD imo.

I agree, this sounds like a completely normal process of finding and fixing bugs.

The stack trace tells you where the error is occurring, your intuition leads you to the relevant caller function that you should test, stack trace or logs should lead you to the offending parameters (i.e. the weird name).

With these three pieces of information you can write a failing test and implement a patch.

I don't consider this approach to be "TDD", just "software development with good test coverage".

> Tests make refactoring slower, because you might have to also update the tests

No, tests can make refactoring slower, because they often test implementation detail instead of interface. Being able to distinguish the two is not as easy as it sounds, typically it requires deep understanding of the domain, which people writing tests might not have yet.

> in a complex enough code base, refactoring is impossible without sufficient test coverage

Sure, and in my experience complex code bases are typically complex due to the amount of accidental complexity, not because they actually solve complex problems. Like layers of overengineered classes intertwined through dependency injection for the sake of being more... testable. See the irony?

And indeed, refactoring becomes quite hard. You have two options to make it easier:

1. Identify and remove accidental complexity.

2. Cover it with tests and set the complexity in stone.

It's like fighting cancer with painkillers. It might look like it's working, but you going to die pretty soon.

> Test that this code called from a tight loop doesn't query the db hundreds of time which would lead to the startup time taking minutes rather than seconds

Oh, this is a great example. I saw the exact same thing implemented couple years ago. The whole team hated it because it caused tests to break constantly. And yet nobody on the team had the balls to remove it, and they were even following the pattern for new tests, because past tests had it.

If startup time matters for your app, there will be plenty of signals apart from tests that it's broken. If startup time doesn't matter, why are you testing it?

By the way, you haven't even noticed it, but you conflated startup time with number of queries. You're testing the wrong thing. What if hundreds of queries are still blazingly fast (due to being simple and/or cacheable) and have negligible effect on startup time? What if existing startup time is already extremely high (e.g. you're loading ML models in memory)?

If startup time truly matters for you, you shouldn't be testing it, you should be monitoring it. And I'm not even talking about some complex monitoring systems. When someone on your team says their developer experience got worse, that's the type of alert you need to listen to.

Quite frankly very few people can do TDD well. Hence why most developers hate it. They've never been taught by a master.

The majority of developers have less than 5 years experience, and they're teaching new devs. So the skills that we're developed by people who embraced TDD in the early 2000s have been swamped out by new people.

I think the best way learn if you don't have access to a master is probably videos. See if can find kent beck doing some examples. There's subtle knowledge & flows that hard to teach through just text alone.

I think you are doing it correctly, you just need to break that iceberg into smaller chunks. You’re getting caught up in the ideological nonsense that surrounds TDD and Scrum. “It can categorize a single transaction correctly” should be translated to a problem statement, “I want to be able to categorize a transaction.” You must then brainstorm feasible solutions for this or different aspects of the problem, develop the spec for implementing that, in the form of tests, “able to do this, able to do that,” and build the solution. Then afterwards you can test it against some examples and ask yourself, does this solve the problem? How to improve? Come up with a change or completely different solution, rinse, repeat. I would say a general statement like categorize a transaction is difficult because you don’t have any specific examples. Come up with a list of a dozen transactions that need categorizing and your TDD experience will become much less frustrating.