Do everything in Java…

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Fri Dec 5 05:54:19 PST 2014


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.


More information about the Digitalmars-d mailing list