@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.

@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.

@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?

@RonJeffries @jmeowmeow @searls
No, just getting to green super fast by putting in the app what the test expects.

Then replacing the result with computation is my "refactoring" step. Actual refactoring in the sense of design change follows, but only if I don't like how things look.

The "pre factoring" I typically only do if I can't figure out how to write a simple test.