All Downsides and Open Questions of TCR
Your help is required: Please comment all possible downsides and open questions! I will collect and aggregate them, so that they can answered by someone.
When I create new projects or adopt new practices, I like to know as early as possible all the negative aspects of it. Especially the ones, that make me not doing the project / using the technique.
Usually, this process includes a lot of googling, listening to podcast and going to conferences and meetups. With TCR, this is different, because it is quite young and very immature (barley nobody uses it day to day, no one, I am aware of, at scale).
Therefore I’ve started this collection of downsides and open questions, that I will update. Discussions after my talks and workshops on TCR are the resource for the points. But I also keep an eye on the critics on the web. They usually are rude (sad) but are a great spring on inspiration for this article (they usually formulate one particular problem and not the root of it, so even here I have to do some work).
Not exaclty sure, what TCR is? Check out TCR (test && commit || revert). How to use? Alternative to TDD?
Your help is required!
I did not come up with the most points by myself but got them as feedback, or we found them in discussions. Please read some articles on TCR and write the downsides in the comments. As soon as we have a nearly complete list, we can solve them holistically and TCR could become “production-ready.”
Start here: test && commit || revert by Kent Beck and maybe get some more input here: TCR (test && commit || revert). How to use? Alternative to TDD?
The downsides/questions
Note: My possible answers are cursive
Note: The points are brainstormed and therefore unedited and unsorted
When I develop an algorithm, that I found in a math textbook, I can’t do mini-steps. I quickly find mini-steps with tests for the first steps, but the generalization happens in a big step. This big step is dangerous with TCR.
Personally, I think, this is a solved TDD-problem, but I keep hearing this.
TCR does not work if my test-suite takes too long
TCR is very painful if you have flaky tests.
What happens with long-running tests? (Limbo problems)
What happens Integration Tests?
The global test suite takes longer than the frequency of new commits. No matter, how fast the tests are. (Limbo problems)
The Git-Log does not serve it’s purpose anymore. We are abusing Git!
Github is probably not happy when anyone does TCR + Limbo.
My TCR-Script is broken! (This means, that something with the tcr.sh script does not work, for example, you messed up with the &&s and ||s. Or your IDE doesn’t do auto-reloading. This point comes from the prototype state of TCR)
My IDE does not sync with the filesystem!
Do I have to write my very own implementation of TCR?
How to handle non-functional requirements like security, when changes pushed to production immediately? (Limbo problems) -> Related to Continuous delivery
With interpreted languages, no BTRC (build && TCR) is possible. When I have a typo, TCR reverts everything.
I can never see my red test, to check the usefulness of the error message (keyword: test as documentation)
I cannot verify if my test is worth anything because I never see it red (TCR keeps you always in a green state)
My tests vanish, when I make a mistake
What happens, if I am creating an algorithm and I am halfway done (it is a complex one). Now my colleague uses it and depends on an not finished algorithm. His code now always breaks, when I start developing. I do not want to be responsible for his code.
“another smell for me when talking about “my” code, “his” code, … Pursue teamwork and communication.” Raquel
In TDD, it is possible to trough a test-runner, only to run the current test. This selection of tests gives you a significant speedup. From time to time, I run all the tests. These days, with TCR this is not possible. TCR is therefore too slow, as every iteration takes at least x minutes (because of test-time).
How can I start using TCR in an existing code-base?
Must I to structure my project in another way with TCR?
tl;dr Yes. Article in work
Have you explored code reviews (i.e: review board) along with this approach? Where/how do they fit in?
With TCR, you write mini-tests, that only test only one very tiny thing. With these tests, you compose your feature more and more. But this leads to useless tests: You firstly create a test, that only covers a part of the desired feature, then a test, that includes the test before + more. You actively have to hunt for the use-less test-cases as they blur the documentation-purpose.
If you don’t know enough techniques of TDD you can become afraid of running the tests, as you are not confident, that they pass and revert your big change.
Should I include linting?
Should I include fail on warning (fail build, if there are any warnings, not just errors)
False Green Problem: Test is green, but actually should be red. In TDD, you prevent this with the policy, that your test always is red first. With TCR and “write test + fake”, this is no longer possible.
Can I combine TCR with TDD?
Should I really use Git for TCR? It feels, that I abuse the tool for something it is not made for.
It is easier to get stuck with refactoring. Fowler allows being in red for a short duration, TCR not.
You get stuck more easily as in TDD as you are not allowed to act in red.
TCR is more advanced, as you MUST know the practices, that you CAN use with TDD. So the learning curve is steeper.
“I wish I could get paid to write substring functions that are pure, have no class dependencies or don’t depend on existing code/frameworks/libraries. What a utopia you live in!” -> TCR is not real-world ready.
You always read these unconstructive comments. Sad…
Does TCR work with mocking, faking, stubbing, etc?
How to make sure, that you don’t write tests, that are always green?
So every time you typo a variable or function name, rather than just correcting it, you have to type out your code again?
I don’t trust tests that never failed.
When you force people to do TCR your test-quality is equivalent as if you force them for 100% test-coverage, isn’t it?
Is TCR just a faster version of a Reviewer, that rejects your code, if it fails or does not have enough coverage?
Nice idea, but no
TCR does not scale!
When I report a bug, I write a failing unit-test to demonstrate it. Is this possible with TCR? I think it deletes my test.
“I have no idea how this should work on a big refactoring where you touch every single one of your.. say 200 files and add something to every single method.” HackerNews
Thank god for buffers / ctrl-z
