Sorry to belabor the point. Again, if what you're doing works for you, more power to you. However, your unit tests should survive starting with one file and bre

Sorry to belabor the point. Again, if what you're doing works for you, more power to you. However, your unit tests should survive starting with one file and breaking it out into multiple files. That's exactly what evolutionary design is, and how I program too. If your tests can't survive it, they're probably too caught up in implementation details. (Or you've fallen into the common trap of defining "unit test" too narrowly.) Also, if you haven't read it, check out Martin Fowler's Refactoring book. It shows how you can do things like splitting one file into multiple without rewriting. What I do is test-drive the simplest implementation I can think of, which will often be one module or class, then factor out additional classes as I discover them. While I'm doing that, I'll leave my tests as is, and they continue to cover the code equally well. As I split things out, I'll typically discover more edge cases I want to support, and I'll test-drive those edge cases as well. I'll typically move any relevant tests at that time, possibly rewriting them to be more specific to the unit under test, but the important thing is that I don't have to, and I'll wait until I have the design figured out in my head before I do so.