TCR test && commit || revert -- Rope in Python 3/3 -- Make it Right

[@skipodap1]

The artifact of this video is a demonstration of the TCR process, not the code itself. Let's be grateful that this legend of software is taking the time to share this with us. (fwiw, i think the code turned out quite nicely)

[@ProgramArtist]

Thanks for the videos and the experiment. A few questions and remarks: 1. How can you write the tests and the code in different files? It seems like you must first combine the 2 in the same file and then somehow split them. 2. Also, it seems like its quite easy to add untested code. For example, the test that is written at 30:00 is being deleted at 30:36 and never added back, and it can easily be missed. 3. For me it creates an anxiety feeling and disrupts the flow because I must think about the timing of the save, the deletion of the test is a very big minus. (I'm used to save every time I stop typing for even a second). 4. The revert is actually bugging me more than it benefits me from what I see. Seeing the failing red error is a good enough feedback, the revert step doesn't add real benefit for me, mainly annoyance. 5. If there was a way to write the failing test and commit, it would be great. If there was some 'yellow' test state which means the test fails but its ok since it's WIP, and we can commit if there are no red ones. 6. I find myself using the failing tests as a marker, when I come back to the code I know how to continue. 7. The TCR forces you to never see the red tests, so it's harder to perform on more complicated code and tests to make sure the test actually tests anything. It requires an extra step of deleting the last implementation and seeing it revert back.

[@KentLBeck]

Great questions. Try it yourself. Modify it to suit your preferences. See what you learn.

[@subtleGradient]

T&&C||R is still my favorite game. It’s like a battle of wits against myself 😜

[@NicholasShanks]

Hi Kent. I've been doing TCR full-time, in production within a small team, since discovering it one week ago. I did not have my tests auto-run on save as you demonstrate, but run them manually when ready to, once every few minutes or so. Watching these videos (and not being a Python programmer) I have two things to note: at 25:30 you should have just done `return Substring(self, index, index + 1)` - not only would you have not had to implement get_single_item, but it would have made the code more self-similar within that function, and the interface would always return a Substring. Secondly, whilst unnecessarily implementing get_single_item, the test you wrote at 29:50 disappeared when it failed at 30:35. You then carried on writing implementation, saying at 31:06 “Now this will definitely pass” not noticing that the code you were writing was no longer under test, so of course it wouldn't fail! Seeing a test fail, to ensure that the test is actually testing something, is a critical part of TDD that TCR takes away. And as you show here, for TCR to be effective, it requires you to remember to always re-write any test that failed on it's first implementation; people are fallible and should not have to remember to re-write such tests every single time. I don't have a good solution to this, but there needs to be a middle-ground where failing tests are immune from reversion until correctly faked. The only way I can think to do that is for new test cases to be in a file not under revision control. Perhaps ./new_test.​py could be added to .gitignore, and `cat new_test.​py >> good_tests.​py && echo "" > new_test.​py` inserted into your TCR script before the commit step. Frequently refactoring good_tests.​py so that its contents live in the correct place would then be needed.

[@osherel-netanany5252]

im missing the setup of the mechanics that commits and reverts automatically.... what does it do? git add ? what commit messages does it use? is it a VS code plugin? where does it come from?

[@ebrahim_radi]

what about to_rope('abcde')[0:2:5] ? Also, instead of creating __get_single_item__ and implementing of it in subclasses, maybe you could use __get_item__ recursively. so if it was int, simply return Substring(self, index, index + 1)

[@ebrahim_radi]

also to_rope('abcde')[-1]

[@JohannesBrodwall]

You could simplify the call and use of the class Substring by making these arguments also start, end instead of start, length PS A VS Code trick: without having anything selected, try hitting cmd-c, cmd-v. 😉

[@veganaiZe]

Methods with leading + trailing __doubleunderscores__ are reserved in Python. We're not supposed to go around creating them willy nilly. It's okay though; I won't tell Guido. I really like the simplistic approach you've taken (with Python)!

[@JohnCaruso]

Regarding Inline method refactoring you had to do manually for __len__ return self.length(), it is unfortunate that VS Code's refactoring capabilities are still lacking. While I also use VS Code, I use WebStorm when I have big refactor jobs. I tested refactoring similar JavaScript code and WebStorm inlined the method call without a problem - it even prompts whether all calls to the method should be inlined and whether the method should be kept vs removed. I would imagine JetBrain's PyCharm IDE offers same functionality for Python. JetBrain's refactoring support is best of breed.

[@DerPumu]

I'm pretty sure PyCharm does that, as even CLion which has basic Python support has that kind of Python refactoring support

[@pendax]

Why is it called Rope?

[@l_combo]

because it's related to string ;)

[@danielwilkowski5899]

Because it's a bunch of strings tied together. Kent mentions it in the first video of the series.