Code without tests is bad code. Even if it’s looking clean and efficient. Without tests you can’t change it in a verifiable way.
You can’t know if your code is getting better or not.
It’s not a new idea.
But it’s amazing how many times developers will ‘cut’ corners or won’t implement tests because they are too busy to ship a new feature.
In many cases, it’s the opposite case, if you wish to move faster and safer – you need a good tests suite that give you the confidence that your changes didn’t break anything. You wish to have unit tests (wide coverage of functionality and running fast in an automated way), integration tests (a bit slower but still fast and in many cases, with mock data) and end to end tests (Yes, in many cases, in a real production environment).
Like most things in life, it’s not black and white. There are many cases, where it’s easy to say “you need tests for this service” but it’s real challenge to create and maintain a reliable testing environment.
However, if you keep in mind, that you want your code to be testable, in most cases, you will be able to do clear things to mock objects and have a set of reliable and automated tests.
If we think on the 20/80 rule here. The 20% of tests that cover 80% of our system could give us a nice ROI. For the last 15%-20% of our system, we can use production with live A/B testing to get a good validation for our changes or additions. Many companies are doing testing in production all the time in order to find out what is working and to fine tune their current performances. The real good companies, bring these A/B tests to production only after they have a good confidence in the quality of these changes.
Btw, this came earlier today and the replies there are good validation.
Ido Green 