3 ms·

Designing the tests means you have to design the software. This is a low-key way of enforcing some upfront design, which is good. Also, this is not specific to

Designing the tests means you have to design the software. This is a low-key way of enforcing some upfront design, which is good. Also, this is not specific to software. Defining how you will validate a system, before you go build the system, is simply good engineering.

deleted 2y ago
[deleted]
jandrewrogers 2y ago
The design of some software, even in substantial detail, is not sufficient to design tests of an implementation. Good tests can be completely dependent on the implementation details far below the level of design because those implementation details determine how the thing you are testing can even be measured. How it is measured isn’t actually important. You can get closer with extreme (over-)specification of the implementation, which almost no one does because it comes with an inordinate cost, but even that can fail because software properties are also a function of the hardware it runs on. To some extent, modeling the interaction of software on hardware for the purposes of building good tests is by actually measuring running code on real hardware. Hardcoding specific implementation detail assumptions into the design of complex non-trivial systems so that you can write a test is a brittle way to go about writing software. There is a reason that waterfall-style never seems to produce good systems in a reasonable amount of time or money. I write non-trivial greenfield systems and put inordinate amounts of design work into them (literally years in some cases). I have never found a case where that allowed me to write useful tests prior to implementation. At a minimum you need a complete architectural skeleton that runs and has had its non-functional properties verified analytically before you can write tests that you’ll likely use. I’m not against writing tests. I invest far more in testing than most devs due to atypically high reliability and robustness requirements. I’m against the complete waste of time that would be writing tests before there is sufficient implementation to design maximally efficient and appropriate tests. Testing of some software is extremely expensive in both time and money, so optimizing test effectiveness and efficiency becomes valuable.
TeMPOraL 2y ago
Designing tests at the unit level requires you to design low-level/"tactical" aspects of your software, which automatically forces you to commit to a certain general/"strategic" design of the overall program. This is often the opposite of what you want in greenfield work - you want to first rapidly explore the space of high-level designs, not precommit to the first one you thought of that makes tests easier. Starting with TDD is like being a general whose recommendation to every international politics issue is to commence training for a combined arms assault on the capital of the country's historical enemy, because that's something that can be iterated to provide good estimates and error-free execution. Except, that general misses other, possibly much more effective approaches, such as airstrikes, assassinations, supplying domestic terrorists in enemy territory, or... not shooting anything at all because we're not at war and the problem can be trivially solved by respective VPs over some drinks. Or the problem isn't even a problem. Keep the TDD General around for when you're actually fighting a land war - but for the love of $deity, don't let him drive international policy in peace time.
- hitchstory 2y ago
  TDD != starting at unit level. It's about red-green-refactor. Or, it should be anyway. People talk about how it "drives" design but I dont think it should. I think tests should be as design-agnostic as possible, providing freedom to redesign. I always start with an end to end test. These dont force you to commit to anything.
  - voiceofunreason 2y ago
    There is definitely room for confusion as to whether the "design" that is "driven" by TDD is design-the-noun or design-the-verb.

deleted 2y ago

[deleted]

jandrewrogers 2y ago

The design of some software, even in substantial detail, is not sufficient to design tests of an implementation. Good tests can be completely dependent on the implementation details far below the level of design because those implementation details determine how the thing you are testing can even be measured. How it is measured isn’t actually important. You can get closer with extreme (over-)specification of the implementation, which almost no one does because it comes with an inordinate cost, but even that can fail because software properties are also a function of the hardware it runs on. To some extent, modeling the interaction of software on hardware for the purposes of building good tests is by actually measuring running code on real hardware. Hardcoding specific implementation detail assumptions into the design of complex non-trivial systems so that you can write a test is a brittle way to go about writing software. There is a reason that waterfall-style never seems to produce good systems in a reasonable amount of time or money. I write non-trivial greenfield systems and put inordinate amounts of design work into them (literally years in some cases). I have never found a case where that allowed me to write useful tests prior to implementation. At a minimum you need a complete architectural skeleton that runs and has had its non-functional properties verified analytically before you can write tests that you’ll likely use. I’m not against writing tests. I invest far more in testing than most devs due to atypically high reliability and robustness requirements. I’m against the complete waste of time that would be writing tests before there is sufficient implementation to design maximally efficient and appropriate tests. Testing of some software is extremely expensive in both time and money, so optimizing test effectiveness and efficiency becomes valuable.

TeMPOraL 2y ago

Designing tests at the unit level requires you to design low-level/"tactical" aspects of your software, which automatically forces you to commit to a certain general/"strategic" design of the overall program. This is often the opposite of what you want in greenfield work - you want to first rapidly explore the space of high-level designs, not precommit to the first one you thought of that makes tests easier. Starting with TDD is like being a general whose recommendation to every international politics issue is to commence training for a combined arms assault on the capital of the country's historical enemy, because that's something that can be iterated to provide good estimates and error-free execution. Except, that general misses other, possibly much more effective approaches, such as airstrikes, assassinations, supplying domestic terrorists in enemy territory, or... not shooting anything at all because we're not at war and the problem can be trivially solved by respective VPs over some drinks. Or the problem isn't even a problem. Keep the TDD General around for when you're actually fighting a land war - but for the love of $deity, don't let him drive international policy in peace time.

hitchstory 2y ago
TDD != starting at unit level. It's about red-green-refactor. Or, it should be anyway. People talk about how it "drives" design but I dont think it should. I think tests should be as design-agnostic as possible, providing freedom to redesign. I always start with an end to end test. These dont force you to commit to anything.
- voiceofunreason 2y ago
  There is definitely room for confusion as to whether the "design" that is "driven" by TDD is design-the-noun or design-the-verb.