TCR methodology makes it easier to follow a development process for it forces you more to figure out a way to have always a functioning state. So while you might be missing some aspect of the code that you’re still not developing, taking that feature itself layer by layer, step by step, and, because when you fail the test, your code should be reverted it forces you to make smaller commits.
A problem with small commits is that when you go look at your history of changes up to your latest commit you have to scroll through 20 of them for the latest thing that you did so it’s more convenient for small teams than bigger where it can become annoying to revise all of them, but the good thing I see about it is that if it makes you have to solve and figure out so a way you can make the least amount of changes while still getting closer to your goal.
In a way it helps optimize your code and you make sure let you never go too much ahead or that you get used to the idea of “if I do too many changes without testing I’m going to lose them, if I have a simple syntax error so is it worth it to try and do everything right the first time”.
SWqualityandtestingTC 