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…
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…