Slides of the workshop co-facilitated in Stockholm https://www.meetup.com/es-ES/Stockholm-Software-Craftsmanship/events/259388924
The goal was to get to know the TCR workflow, try it in a couple of katas and learn something new, whatever it is :-)
"test && commit || revert"
Stockholm, 12th March 2019
1. Review of TDD
2. New workflow: TCR (test && commit || revert)
3. Presentation of the kata: Fibonacci
4. First round to try… go!!
5. Second round to try… go!!
6. Opinions and feedback
7. Some downsides of TCR
8. Final recap
9. Interesting links
10. Dinner and networking!
We have not tried TCR with Production code
We are learners
We are here to practice and learn the new workflow
A new workflow: TCR
Popularised by Kent Beck after post in September 2018:
Experiment in Code Camp by Oddmund Strømmer, Lars Barlindhaug and Ole
Basic idea: test && commit || revert
TCR: an oversimplified diagram
write your code
TCR complete diagram
Repository with TCR scripts
Kata: Fibonacci sequence
Reminders for the set up
● You need Git installed
● Disable the auto-save mode
● Be sure your files get refreshed in your IDE (or you can force it easily)
● If you’re not using Java, Ruby or Python, there is a generic template
First pomodoro… go!
● Have you tried recursion? And memoization?
● Try another kata, e.g. substring kata:
Second pomodoro… go!
Opinions and feedback
● Did you learn anything new?
● Which was your main pain? With what did you struggle specially?
● Would you apply this during your daily job? Why? Or why not?
● Even if you don’t apply TCR tomorrow, is there any other practice you
would consider to apply?
Some possible downsides of TCR
● What if it doesn’t even compile?
○ Problem: a typo/syntax problem triggers the revert
○ Possible solution: include previous step to build/compile, BTCR
● Vanishing tests
○ Problem: everything reverts, including the tests
○ Maybe not a real problem: it forces you to nano-steps when writing tests!
○ Possible “solutions”:
■ commit the test first being pending/skipped
■ pass the negation of the test
● False green
○ Problem: If you don’t go red first, you might be adding a test which does nothing
○ Possible solution: negate the test after passing, and see how it reverts
● Fast feedback is more important than ever…
● Forces nano-baby-steps
● Forces you to think: "how can I make this change with a smaller step?"
● High frustration at the beginning?
● Beware the downsides…
● Kent Beck screencast: https://www.youtube.com/watch?v=ZrHBVTCbcE0