4 ms·

I too find it hard to apply TDD to the big existing project I am working on. Most of my day-to-day coding is adding small bits here and there in the right place

I too find it hard to apply TDD to the big existing project I am working on. Most of my day-to-day coding is adding small bits here and there in the right place, discovering the architecture of the whole thing as I go. Without knowing what I have to do to achieve the desired result in the first place, I cannot begin writing a test with the half dozen mocks it needs (I know it's bad). The only tasks where I can succesfully apply TDD are bug fixing, where I write a new test to prove that I understood the bug (the test should fail with existing code), before I fix it. But I have colleagues (working in other projects) who told me how they are succesfully applying TDD to refactor an old codebase. They start with big, not-so-"Unit" tests to make sure that they don't break the thing at any step, and then they move to more specialized tests when tackling specific parts of the code.

motorest 2y ago
> Most of my day-to-day coding is adding small bits here and there in the right place, discovering the architecture of the whole thing as I go. Without knowing what I have to do to achieve the desired result in the first place, I cannot begin writing a test with the half dozen mocks it needs (I know it's bad). Nothing in your example prohibits or even hinders TDD. The only thing required by TDD is that you specify an interface and add tests to specify what behavior you expect from them. The moment you have something you can compile and run, your TDD path is completely open. Also, I'm noting the hints of the same specious reasoning that plagues discussions on microservices, mainly the "it's-all-or-nothing" fallacy. You can benefit from TDD if you, say, are writing a RESTful interface and start off by only adding unit tests checking for controller behavior. If your project can live with 0% line coverage, it can certainly live with TDD buying you 20% line coverage.
nunez 2y ago
Your situation is the best opportunity to add tests, IMO. The codebase is mature and it's architecture is likely well established. It's easier to write tests for small changes in a very established system than it is to write tests for a system that's still in flux. In most cases that I've seen, this isn't done because there's no financial upside to doing so. When your bonus is tied to velocity, not quality, any effort on testing is too much effort.

motorest 2y ago

> Most of my day-to-day coding is adding small bits here and there in the right place, discovering the architecture of the whole thing as I go. Without knowing what I have to do to achieve the desired result in the first place, I cannot begin writing a test with the half dozen mocks it needs (I know it's bad). Nothing in your example prohibits or even hinders TDD. The only thing required by TDD is that you specify an interface and add tests to specify what behavior you expect from them. The moment you have something you can compile and run, your TDD path is completely open. Also, I'm noting the hints of the same specious reasoning that plagues discussions on microservices, mainly the "it's-all-or-nothing" fallacy. You can benefit from TDD if you, say, are writing a RESTful interface and start off by only adding unit tests checking for controller behavior. If your project can live with 0% line coverage, it can certainly live with TDD buying you 20% line coverage.

nunez 2y ago

Your situation is the best opportunity to add tests, IMO. The codebase is mature and it's architecture is likely well established. It's easier to write tests for small changes in a very established system than it is to write tests for a system that's still in flux. In most cases that I've seen, this isn't done because there's no financial upside to doing so. When your bonus is tied to velocity, not quality, any effort on testing is too much effort.