3 ms·

I regret using the word "refactor" in the context that I did, because I think we're talking about slightly different things. A better way to word it would be t

I regret using the word "refactor" in the context that I did, because I think we're talking about slightly different things. A better way to word it would be that I would have to rewrite both my code and the tests many times. When I'm in the exploratory phase, it's not just the implementation that's changing rapidly, it's the interface and structure of each piece too. I find it far more natural to discover as I go, even though that means I throw away a huge amount of the total code I write. Consider the GP comment's example of having everything in one file to begin with, then splitting it out into separate pieces as becomes apparently appropriate. There's no unit test that would survive that process without equal levels of modification, even though the overall behaviour of all the pieces when combined never actually changes. I suspect most developers have got a lot more of this stuff ironed out before they actually start writing code, but my brain doesn't work that way. Thanks for the recommendation too, from the introduction that article looks really interesting, I'll be sure to check it out.

jdlshore 3y ago
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.

jdlshore 3y ago

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.