> Never change your code without having a red test
I'll never understand why people insist on this. If you want to write your tests first, that is fine. Noone is going to stop you. But why must you insist everyone does it this way?
I'll never understand why people insist on this. If you want to write your tests first, that is fine. Noone is going to stop you. But why must you insist everyone does it this way?
I write testable code without TDD and if something breaks we write test to cover that case so it doesn’t happen again.
You don't want money and ledgers going out of sync. That can be serious.
When you created or found a new way do approach development and you want to spread that idea, you want to persuade.
Alternatively you may want to inform, for example when you teach or journal. In which case you write down the facts without embellishing them.
Finally you may want to do a critical review, then you explain the method in relation to other methods and existing practices. Pros and cons, etc.
The hope is that the reader will understand these goals and adopt it into their own beliefs as they see fit in relation on how it was presented.
All these programming methodologies seem to be in risk of developing a cargo cult following and since programmers are way more dogmatic than people it also gets way worse than in other fields.
I don't like TDD and I think it is silly. But fine whatever floats your boat. The problems begins when someone tries to push the single right way onto others and it seems to mainly be a problem in corporate settings where most people rather get money than doing what they think is the right thing -- and some people push agile, TDD or whatever.
That said, this workflow is tedious during the exploratory phase of the project. If you're unsure yet about which entities should exist, and how they will be used and interact with each other, TDD can be a hindrance. Once the design is mostly settled, this workflow can be helpful, but insisting that it must be used always is also annoying. Everything in software development is a trade-off, and dogmatism should be avoided.
Often I do not have the clarity to write the test first, then I just write the code and the test later. But I comment out the code or introduce a bug on purpose to make sure when I run the test code it actually works and detects the bug.
A particular test has assertions that must be implemented correctly in order for them to pass.
By starting in red you gradually make your way towards green usually paving your thinking and potentially unlocking other tests.
I don't believe you must do this every time though.
So I think we agree. If you find it beneficial, please carry on doing it. For anyone who doesn't find it beneficial, they can write tests in whatever way they want.