Understanding Legacy Code with TCR (test && commit || revert)

[@orlovskyconsulting]

Mr Beck i consider you as one of my main mentors into professional software development area , great that you have a youtube channel you can share a lot of insights and we your students will extend and teach others, there so few developers who really care about what they doing and huge thanks for Junit!

[@thomasdeniffel2122]

I think TCR is a good fit here. Like refactoring, it is an always-green scenario, as you never want to have an assumption (written down as test) that is wrong. As soon as you have a wrong assumption, TCR kicks the wrong assumption out of the set of assumptions (all tests). There are only two ways out of a false assumption: Change the set of assumptions/tests or change the code. In TDD, you make a "wrong" assumption and fix the code. Here you want to fix the assumptions. So why don't automate it via TCR? When you refactor, you expect that your assumptions (= observable behavior) do not change. If they change, you want to change the code back - also possible to automate it via TCR.

[@ProgrammingwithMaria-id4gd]

Kent Beck is our Hero. And its my luck that i got a chance to have a session and opportunity to meet with Kent.

[@islamabbas5718]

Thank you so much. Nice and interesting post. Waiting for more please Mr. Kent

[@russellf]

Very interesting. My only concern (as someone who hasn't tried this yet) is that in many cases (and perhaps in other languages?) it is hard to add such small amounts of code at a time. The idea of losing code (that's not still in my clipboard buffer) due, e.g. to a typo, would contribute to my anxiety which is contrary what TDD usually reduces.

[@skipodap1]

this is great. This is also kind of like a "learning test"

[@minh-tamtran1151]

Thanks for the video ! May I make an observation? Some people believe unit tests should cover only requirements. If something ain't tested, it means it's not part of the requirements and can be changed (ex: should the output collection of my function be sorted?) without breaking the contract. Some people believe unit tests should help readers understand the behavior of the code. Kind of what you are showing in this video. As a side note, the behavior contains but is not limited to the contract. My reflection so far seems to show the existence of at least two types of unit tests : unit tests expressing requirements, and unit tests helping people really understand the unit (there may be already tested code in these, as well as behaviors that are not in the requirements) When, just like in this video, one co-worker feels they need to see for themselves a certain unit test in order to trust their understanding of what a function does, I tend to think that others will feel the same need. Hence the value I see in such unit tests for helping understanding the code. The reflection would lead me to having two sets of unit tests : one for the requirements, and one for all the behaviors that fellow developers felt they needed to see work in order to understand the unit. What do you think of the duality I seem to perceive?

[@matheusaugustodasilvasanto3171]

I think that's a very poignant observation. I believe automated tests can also serve to document counterintuitive / unexpected behaviors in the unit. For instance, behavior with input values outside what's observed in normal usage of the system. The distinction between tests that validate functionality needed for the requirements and tests that validate "all" functionality might be done via acceptance/unit level tests. Acceptance tests may even use the same APIs as unit tests, but they only document system behaviors that matter to the end user. Unit tests are primarily to drive development (in my opinion), and as such are a suboptimal place to document requirements.

[@ed2bbr]

It's really a good practice. I'm working on a project that we need to refactoring (and we don't have any test at all). This practice is helping me to understand the code and gave me more confidence "to make some mess in my tests :D" Thank you Kent and Kelly

[@Tekay37]

I wonder how you manage the massive changelog. Do you squash commits when merging the branch? Or do you ammend your commits into a single commit that will be pushed?

[@palimondo]

When you follow the link at the end of the video, you’ll find that the contents of the tsc.sh is just the following one-liner: (rspec && git commit -am "WIP") || git checkout .

[@NguyenTung-ss8cq]

What an interesting technique.

[@thatoneuser8600]

My conclusion from this video is that you should use TCR when attempting to understand a codebase or refactoring the codebase, and that you should use TDD when adding functionality to the codebase or fixing a bug in the codebase.

[@mmelt]

This is a wasteful engineering practice with almost zero real world value ("Sorry boss, had an unproductive day and I've nothing to show for it - too many typos this morning!"). Unfortunately, as is the case with many quack practices, once you give it a name, write a few blog posts or demo it, someone inexperienced will come along and adopt it, ultimately giving the pointless practice a non-zero value. If it works for you, that's fine - modern Perl, Dvorak keyboards and 36 hour days work for some people - but please don't try to force this into the main stream.

[@KentLBeck]

You speak with such confidence.

[@XavierBrinon]

@@KentLBeck I'm gonna reuse that one ^^!

[@christernilsson1]

Kent Beck has an outstanding track record and is thinking loud about TCR. What do you have, except an empty KZbin account? TCR is a really interesting idea. It is way too early to dismiss it. If you have any good practices to recommend, speak out. Otherwise shut up.

[@mmelt]

@@christernilsson1 I'm not sure what point your is - an ad hominem attack and appeal to authority is juvenile at best. Try not to confuse effort with value: only value pays the bills. Anywhere void of criticism is an echo chamber. While I know TCR has value in automating monorepo merge windows it's not something that should be adopted by us flawed humans because - as I outlined above - it is an extremely wasteful practice. If TCR takes off I'll never be able to ship a product again.

[@christernilsson1]

Matthew Melton. please, could you state why TCR will not fly?