It’s funny, but there has long been a paradigm in programming called test-driven development or TDD. The idea is that you have a small number of experienced developers who write a suite of tests that an application has to pass, and then you let an army of newbies write whatever the hell they feel like writing and if their code passes the tests it goes into the application (somewhat snarky summary but not entirely). In my experience it does not produce solid applications but a large fraction of the programming world swears by it. I’ve always thought that the construction analog of TDD would be letting a bunch of inexperienced workers build houses and then the experienced contractors drive around in bulldozers knocking down anything that happens to not be built well enough.
You know what real life scenarios you’re solving for. Basically, this is the problem statement of your design.
You write out these tests to say your service must pass these tests in order for it to be considered working. In order to consider problem x solved, the service must do y.
You make the first iteration of your service to just repeat exactly what the tests want it to output (basically to create a skeleton with a bunch of magic numbers)
You make the second iteration. What magic numbers can you remove and actually implement for? What workaround can be fixed? Are they still passing the test? If they start failing the test, you should relook at what you wrote and debug from there (this assumes your tests are rightfully written).
You keep continuing with that process until you have a service that fits your test cases and without mocks
The obvious flaw is that 1 is almost never truly accurate. Scope usually changes, and assumptions made probably invalidate your test. It is a valid way of thinking though, because it helps define your expectations, and reduces the likelihood of you making something that misses the target.
For what it’s worth, when we say we do TDD in my team, we write a singular test case that fails, then we implement the production code until the test case works. Then maybe do a bit of refactoring to make it all work nicely together, and only then you start with the next test case.
Writing swathes of unit tests upfront sounds absolutely mad to me, for the reason you state. But also because you do need an API to test against. You can’t write a unit test in complete isolation, pretty much by definition. You can often do so for integration tests, but you definitely don’t want to put all test cases into integration tests, as that increases complexity massively…
I mean, imagine we had Star Trek technology. You can create a 3D model of a house. Press a button, and in a bright flash of light, an entire building appears, assembled by magitech atom-by-atom into a new form. You can literally create a building at a press of a button. And in turn you can also have the building disintegrated and recycled at the press of a button.
In such a world, where the only real work is the design process? Constructing buildings IRL and testing them at full scale would be a perfectly viable way of designing buildings. It’s only completely impractical now due to the immense cost of materials, assembly, and disassembly. The same would apply if you were a magical genie that could simply summon buildings into being.
And that ease of construction/deconstruction is what would be necessary to make construction comparable to programming. All the work in programming is in creating the code. Once something has been written, it takes no effort to copy a file from one place and produce a second copy somewhere else.
It’s funny, but there has long been a paradigm in programming called test-driven development or TDD. The idea is that you have a small number of experienced developers who write a suite of tests that an application has to pass, and then you let an army of newbies write whatever the hell they feel like writing and if their code passes the tests it goes into the application (somewhat snarky summary but not entirely). In my experience it does not produce solid applications but a large fraction of the programming world swears by it. I’ve always thought that the construction analog of TDD would be letting a bunch of inexperienced workers build houses and then the experienced contractors drive around in bulldozers knocking down anything that happens to not be built well enough.
Test driven development is moreso
The obvious flaw is that 1 is almost never truly accurate. Scope usually changes, and assumptions made probably invalidate your test. It is a valid way of thinking though, because it helps define your expectations, and reduces the likelihood of you making something that misses the target.
For what it’s worth, when we say we do TDD in my team, we write a singular test case that fails, then we implement the production code until the test case works. Then maybe do a bit of refactoring to make it all work nicely together, and only then you start with the next test case.
Writing swathes of unit tests upfront sounds absolutely mad to me, for the reason you state. But also because you do need an API to test against. You can’t write a unit test in complete isolation, pretty much by definition. You can often do so for integration tests, but you definitely don’t want to put all test cases into integration tests, as that increases complexity massively…
I mean, imagine we had Star Trek technology. You can create a 3D model of a house. Press a button, and in a bright flash of light, an entire building appears, assembled by magitech atom-by-atom into a new form. You can literally create a building at a press of a button. And in turn you can also have the building disintegrated and recycled at the press of a button.
In such a world, where the only real work is the design process? Constructing buildings IRL and testing them at full scale would be a perfectly viable way of designing buildings. It’s only completely impractical now due to the immense cost of materials, assembly, and disassembly. The same would apply if you were a magical genie that could simply summon buildings into being.
And that ease of construction/deconstruction is what would be necessary to make construction comparable to programming. All the work in programming is in creating the code. Once something has been written, it takes no effort to copy a file from one place and produce a second copy somewhere else.