Justin SearlsMar 14
Pro-tip to any devs who only discovered TDD thanks to coding agents: refactoring is inherently directional. It's more like prefactoring—you rearrange code to make the next change easy. That means you (and your agent) should know the next planned change before you refactor!
Show threadJeff Miller (orange hatband)Mar 14

@searls I wouldn't mind if the pre-factoring mode took precedence.

I take code refactoring as a close analogy to math, where you might re-compose terms of an expression to make the next operation easy.

The other reason to refactor isn't to make the next intended change easy, but to leave the code in a state that's more readable and less vulnerable to rot and confusion.

Factoring up common set-up in tests, and eliminating duplicate re-assertions across cases.

Show threadRon JeffriesMar 14
@jmeowmeow @searls
Yes, I'm with Jeff. TBF, sometimes I do "prefactor", certainly, but more often I'm just making the code more like code should be.
Show threadOrchun KolcuMar 15

@RonJeffries @jmeowmeow @searls

The concept of removing the duplication between test and code was what made it click for me, and that's been the bulk of what I do during the refactoring step.

Show threadRon JeffriesMar 15

@orchun @jmeowmeow @searls
Hm, interesting. I don't often see much duplication of that kind, with the exception of occasional tests to figure out how some bit of the language works.

Are you kind of building up a function in the test and then moving/replicating it in the app?

Show threadJeff Miller (orange hatband)

@RonJeffries @orchun I tend to think of porting logic drafted in the test or test harness into the application as the Russ Rufer and Tracy Bialik TDD technique I encountered at the Silicon Valley Patterns Group.

I have seen a lot of duplication in test cases where new paths or variations are handled by copy-paste without factoring out common set-up or discarding redundant assertions.

Mar 15 at 5:42pmWeb
Show threadRon JeffriesMar 15
@jmeowmeow @orchun
I don't much mind duplication in tests, tend to leave them alone when they work. Of course when I change prod things, sometimes tests must change.
Show threadJeff Miller (orange hatband)Mar 15

@RonJeffries When I refactor a sequence of steps, and several dozen interaction tests break, often needing individual fixing, is an unpleasant experience which has shaped my attitude toward duplication in test cases.

(snipped: a tangent on alternative responses)

Orchestration logic appropriately uses interaction testing with mocks or other doubles. For domain logic, interaction testing isn't my first choice; input and output for representative domain examples is where I prefer to go.

Show threadRon JeffriesMar 15
@jmeowmeow yes. If that happened to me, I'd do the same.