I worked on the proxy and dns software almost every ISP in the world uses today to transfer http and tls traffic. If a bug was put into code it could take mont

I worked on the proxy and dns software almost every ISP in the world uses today to transfer http and tls traffic. If a bug was put into code it could take months where subtle parts of the internet would be failing. This wasn't an option, so we had strict testing. I think for every line of code we had 2 to 3 lines of equivalent test code. From this experience I've found: 1) I found a natural way to write pseudo TDD I prefer. When I'm mocking up some code in a project, I write interface code to run what I'm writing. I run the code from time to time to make sure it's working. If I'm not doing that, how do I know my code it working? You get a sort of dopamine high when running the code and seeing everything come together. What I do is I take that interface code I wrote while creating the code and instead of deleting it, I create a test function (or multiple) and I copy paste it there. If I'm in a hurry I'll come back and write the assert_eq or equivalent later. Writing a test is that quick. You're already doing 95% of it. Just copy paste it into a function. I know it's not always that simple, but often times it is. When approaching testing this way there is no reason not to write tests. 2) Systems tests catch far more than integration and unit tests, so if you're serious about testing, these should be considered. Systems tests go by many different names, so by this I mean a testing echosystem where the system is spun up and a mock client and mock servers are ran. This simulates a real world client connecting to the software and tests the real world results they would get. The reason system tests catch so much more than unit tests is in a large system not everyone knows every functionality and how it should work. It's easy to create a regression where a new feature is added but it changes the behavior of this old previously unknown feature. This often results in going back to the drawing board as it's a business issue more than just a software issue. These kind of bugs can get pretty nasty in the enterprise space if unchecked so it's a good idea to catch them. Furthermore, systems tests catch nearly 100% of what unit tests and integration tests catch as well. This is because if there is a bug in a unit caught, it will propagate out to the client affecting behavior. If it is caught in a unit test and not a systems test, then there might be a hole in systems tests where it's not testing every scenario, or you might have dead/unused code in the code base or something similar. Systems tests I've found are better at catching race conditions as well. Systems tests act as a great source of documentation, because they document how every interface in the program is intended to act. You get a quick high level view and can learn the ecosystem quickly from it, where unit tests are down in the weeds. And finally, you don't need to write anywhere as many systems tests as you do integration and unit tests. You can test a lot more with a lot less work.