@kronn @collin Same. I call this “test second development:” sketch it out first, haggle over the structure, get it more or less working and making sense — the. pull that code out and reintroduce it piece by piece using strict TDD. I use it when (1) reliability is critical or (2) interface will be widely used (e.g. designing a library).
I find this approach leads to far better design than strictly writing tests first. Implementation reveals edge cases, reveals tradeoffs, clarifies intent!