6 ms·

in my experience, taken from projects I worked on with and without tests, even bad tests are better than no tests at all. No tests usually good indicators that

in my experience, taken from projects I worked on with and without tests, even bad tests are better than no tests at all. No tests usually good indicators that there will be a lot of repeated and overcomplicated code. Having a solid test coverage allows you to change/extract functions at any point when you see something is getting outta shape. With no tests, however, it's much easier and less scary to add rather than change. People often make a point that writing tests takes time, but I'm pretty sure it slows you down in the beginning of work and speeds you up quite a bit when you amount some volume, and further you go, more you benefit from having a decent coverage. Also, oftentimes, especially on the server side, it's just easier to implement/verify with automated test from the start rather than by hand. None of it is related to the OP codebase, just thoughts in the abstract.

sibeliuss 7y ago
I tend to think about tests as insurance. Without them, you're flying blind.
speedplane 7y ago
> People often make a point that writing tests takes time, but I'm pretty sure it slows you down in the beginning of work and speeds you up quite a bit when you amount some volume, and further you go, more you benefit from having a decent coverage. I certainly hope that quality testing is more than just your preference or even a good practice: it's now a central part of software development. At this point, we know enough about the benefits of good testing to say that it's practically malpractice to not have them. Good tests may not be a strong enough signal to conclude that a project is good quality, but lack of tests is a clear sign that a project is low quality.