On Fri, Dec 05, 2014 at 11:53:10AM +0000, Chris via Digitalmars-d wrote: [...] > The good thing about unit tests is that they tell you when you break > existing code.
That's one of the *major* benefits of unittest IMO: prevent regressions. > But you'll realize that soon enough anyway. Hahahahahahahahahaha... How I wish that were true! At my day job, you'd be shocked to know how many times things flat-out break in the nastiest, most obvious ways, yet people DO NOT EVEN NOTICE!!!! QA has developed this bad habit of only testing the feature they were asked to test, and the developers have become complacent over time and blindly trusting that QA has done their job, when in reality test coverage is extremely poor, and changes get merged into the main code repo that cause all sorts of regressions. I've had to fix the SAME bugs over and over again in various varying forms, simply because we have no unittesting framework to sound the alarms when somebody inadvertently broke the code AGAIN, the 100th time, 'cos they didn't understand what the correct behaviour should be. Fixing regressions is easily 30-40% of my workload, and almost all of those cases could be prevented had there been unittests to catch regressions. How I wish that with every bugfix I submit, I could also submit a unittest to make sure it complains loudly and clearly the next time somebody breaks it yet again! There are so many corner cases that we fixed over time, that there's no way for QA to practically re-test all of them (plus, without automated tests, how realistically can you do full regression testing anyway?), and I can almost guarantee that many of these bugs will come back as soon as that piece of code gets touched again. We always have to add new features, many of which involve extensive code changes, but without unittests, we could be introducing hundreds of subtle bugs every time, and, given the rate of new feature merges, we could be covering over most of these subtle bugs because code paths have changed significantly. As a result, most of these bugs become dormant in the code, and only show up again years later when a new code change uncovers that code path once more. By then, so many changes would've already accumulated that we may have forgotten what the old bug really was and what the bugfix should be. It may take multiple tries before that bug gets re-fixed. All of this needless churn could be eliminated just by having unittests catch regressions up-front. T -- Debian GNU/Linux: Cray on your desktop.