TCR test && commit || revert -- Rope in Python 2/3

[@anToha_UA]

Good to realise that I am not the only one who does a big SIGH while doing strings offsets maths in my head 16:20

[@veganaiZe]

It actually does makes sense that, in this context, your test can disappear because the test can be the source of the error, itself. So if the test isn't deleted then the source of the problem might persist. If that's too much to deal with then the tests can be stored & versioned separately, in another folder. (But then it may take several tests + reverts until one finally realizes that the test, itself, is flawed -- and not the disappearing code.)

[@mikegehard6402]

This is a really interesting flow...similar to TDD but slightly differnent. It seems to me that this flow does not seem to have an explicit "red" step. Is there any risk here that you could write an "evergreen" test? Or does the small steps help reduce the chances of that happening? Does this flow look any different when using a language with static typing, or even gradual typing in Python, by using type driven development? I've experimented with writing out the type signatures for both functions/data classes (if doing more function focused style) or method/objects (if doing more OO style) but in thie flow it seems like a compiler error would be a failure and cause the code to disappear?

[@pepijnkrijnsen4]

I know you said you were going to make the code more Pythonic in #3, but you defining a 'length' method and calling it as .length() was more triggering than I'd care to admit.

[@PaoloLaurenti]

Hi, simple question: when TCR test fails, why don’t you restart where the failure happened pressing CTRL+Z instead of typing again all the code that went wrong? Love these videos, thanks a lot.

[@mdwhatcott]

I think the idea is to let TCR tell you when you were wrong (by mercifully reverting to the last known working state) so you can have a fresh start. If you work in small enough steps you'll never agonize over losing too much.