I'm currently undergoing a 9-month-long in-place rewrite of testdouble.js (which has proven to be a really stupid idea, but mildly entertaining at least).
This morning, my goal was to break down the responsibilities of the totally not unit-tested td.verify() function with a number of smaller modules which are test-driven with an outside-in approach.
I get a bunch of questions about how I "actually" do this, so I logged each step I took in a separate commit. You can see the 9 steps I took, including the final step—realizing that the contract I'd created was not how I wanted, refactoring one of the dependencies' contracts before it had even been written!
- Psuedo code the module with comments to start shaking out desirable names of dependencies
- Define those dependencies in a test (and then making that test pass by creating the modules)
- Write the first failing test of the happy path behavior
- Make the first test pass
- Write the second failing test of the failure path
- Make the second test pass
- Write the final test of the guard clause
- Realizing ES destructuring didn't behave how I expected when that test unexpectedly failed, make the final test pass
- In response to that surprise, refactor the design to smooth out the ugly workaround
Being able to get critical feedback about my dependencies' relationships before I've invested the time into actually writing them has proven an incredibly valuable time saver over the years, and one of my favorite benefits of outside-in test-driven development