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