I often find it difficult to be productive when practicing test-driven development. This is a pretty common situation. A lot of problems are tough to work out with foresight. I often need to sink my hands into the clay before I totally know what I am building. The TDD feels like adding a layer of cognitive bureaucracy when attacking a problem. But depending on the problem, it is the only way I can wrap my head around it. Typically TDD makes fits my brain when I am refactoring or working out a missing edge case and less-so when building out new features, but even this is not a set rule. It really is case-by-case.
I always thought TDD would make more sense in my process as I became more experienced, but it still hasn't become a productive activity for me a lot of the time. Perhaps it never will.
Top comments (2)
To be fair, I've never given TDD a full swing. It just feels so foreign to the way I view code and it certainly doesn't fit my brain when I'm building something new. It's like putting the scaffolding around something whose shape you can't foresee just yet. There's a place for tests for me. Just not at or near the beginning.
The problem is, I think in our current atmosphere, saying you don't TDD is often misinterpreted as saying you don't test. I tend to test in other ways. I write integration tests at the end of a dev cycle, but I spend most of my coding time working on things like naming and strictness -- neither of which are tests but I'd argue help prevent future bugs better than tests.
I'd rather inherit a codebase that is articulated beautifully with zero tests than one with "100% test coverage" but otherwise lacking in elegance.
Personally, I've found that TDD works well at the Integration/Acceptance/Verification/E2E test level but not so much at the Unit Test level.
The business logic of your application should be well nailed down. The interactions between the "clients" of your app - be that a web browser, a REST API, or whatever it is - should be well designed and documented. And the way that the backend is actually implemented shouldn't change that. This is ideal for a TDD approach.
The individual classes/methods/files/etc in your app are going to be in a high state of flux. They might totally change next week. And as long as they individually work, and deliver the same business logic at the end of it, it doesn't matter. This is less ideal for a TDD approach, but still wants to be tested to ensure that they don't break down the line.