He makes some good arguments for doing top-down TTD using mocks. The biggest point seems to be that it makes top-level design part of the workflow. So there’s less refactoring and it’s easier to get started as you can focus on the big picture instead of writing all the pieces in a bottom-up sort of way.
On the other hand, there’s increased coupling between your code and the tests, which increases the difficulty of refactoring (the main complaint about this approach, which he seems to acknowledge). He suggests that you will have to just rewrite codebases more often.
I wonder if a better “best-of-both-worlds” approach is to just use test doubles (mocks, etc) to get started; and then to implement the component systems just swap out those mocks with actual implementations. At the end you’d be left with a nice suite of end-to-end tests that isn’t tightly coupled to your codebase.
He makes some good arguments for doing top-down TTD using mocks. The biggest point seems to be that it makes top-level design part of the workflow. So there’s less refactoring and it’s easier to get started as you can focus on the big picture instead of writing all the pieces in a bottom-up sort of way.
On the other hand, there’s increased coupling between your code and the tests, which increases the difficulty of refactoring (the main complaint about this approach, which he seems to acknowledge). He suggests that you will have to just rewrite codebases more often.
I wonder if a better “best-of-both-worlds” approach is to just use test doubles (mocks, etc) to get started; and then to implement the component systems just swap out those mocks with actual implementations. At the end you’d be left with a nice suite of end-to-end tests that isn’t tightly coupled to your codebase.