6 ms·
Changing and newly-discovered requirements, rather than tests, drive your code.
by tarkin2 5y ago
Changing and newly-discovered requirements, rather than tests, drive your code.
- Jenk 5y agoDisagree. You are developing to a set of requirements at anyone time. What emerges from (A)TDD is the implementation of those requirements and the design therein.
- tarkin2 5y agoWhen those requirements change, and they can very, very quickly, you need to rewrite your tests--fine if you don't mind spending that time.
- AnimalMuppet 5y agoHopefully you only need to change some of your tests. When your requirements change, and you change your code, you have two questions. First, did my code change do what is needed for the requirements change? You modify tests (or write new ones) to answer that. Second, did I break anything in the process? The remaining tests answer that.
- monocasa 5y agoI've found the flow true for some environments with extremely well defined structures for doing any work (classic backend API servers being one example), but it's definitely not true for all envs. A lot of envs have you spiking so much on just how to even approach the feature that writing tests up front is wasteful overhead.
- cgrealy 5y agoIf you are spiking, then you should be throwing away that code. Don't productionise prototypes.
- monocasa 5y agoDon't just throw untested prototypes in production, but you don't gain anything in a lot of envs by throwing away a prototype completely. You're likely to introduce additional issues by rewriting it for no reason.
- AnimalMuppet 5y agoWell, if a spike is going to become production, when it does, then write the tests (along with all the other cleanup that needs to happen if your going to turn prototype code into production).
- monocasa 5y agoYes, but that model is distinctly not TDD. You came to a design, then backfilled tests.
- AnimalMuppet 5y agoOnly if you keep the design of the spike when you convert it to production. But that should be part of the "production-izing" process, right? You convert it to a solid design instead of a quick-and-dirty hack?
- monocasa 5y agoMost of the time with this model, it's not a quick and dirty hack that is the result of spiking, but the design fleshed out with maybe stubs for a few of the low risk (to the overall design) error pathways. The whole point was getting to a design that fulfills the feature requirements but for which the contract boundaries weren't known going in.
- BurningFrog 5y agoI don't understand the alternative, unless it is to not have tests?
- pydry 5y agoThe dirty secret of our industry is that a lot of the time, we don't. It's frequently scorned but Im not so sure it's always the worst idea in the world. I've built shoddy hacked together systems that made customers happy and wasted months building heavily tested well structured code doing something nobody wants. Well engineered tests take a lot of time to build - sometimes 2x the code itself. If you've built the wrong thing youve paid 3x the cost to figure it out before going back to the drawing board. I'm a big believer in retrofitting tests once code has proven itself useful.
- Jenk 5y agoCode changes when requirements change. I don't think anyone should be surprised by that.
- AnimalMuppet 5y agoBut, given the changing and newly-discovered requirements, letting tests drive the design of the implementing code can still be surprisingly effective. Why? Because if I find it hard to write the test, it's telling me that I'm likely to find it hard to write non-test code that uses the class/module/subsystem/whatever. It forces you to use the interface to your code. If it's hard to use, that's telling you to consider changing the design.
- sidlls 5y agoThis assumes the test isn’t making it hard to use unnecessarily.
- squeaky-clean 5y agoRequirements drive your tests, which drive your code.
- sidlls 5y agoOne doesn’t design around tests, unless the test code is the design spec. In which case something has gone horribly wrong in the requirements and analysis for the project.
- cgrealy 5y ago> One doesn’t design around tests No design gets to the coding stage until someone has answered "how will this be tested?" So, yeah, you should absolutely be designing around tests.
- sidlls 5y ago"how will this be tested?" can be answered without writing a single line of test code or defining what the test suite will look like. The design spec documents determine what the implementation should look like, and the tests should verify the implementation works as desired, not drive its structure. I don't want the implementation to be chopped up and scattered everywhere in the name of "testability" because someone decided that a tool should dictate the architecture of the code. That leads to unreadable, hard-to-maintain, inefficient code that, with a tight coupling to the test suite that makes both them of fragile in the presence of changes in the other. For very little gain.
- cgrealy 5y ago> That leads to unreadable, hard-to-maintain, inefficient code that, with a tight coupling to the test suite that makes both them of fragile in the presence of changes in the other. For very little gain. I completely disagree with everything above. Literally, take the sentence and make almost every word the opposite.
- drran 5y ago