|The stupid question is the question not asked|
Re: MooseX obscure error and importance of Unit Testingby sundialsvc4 (Monsignor)
|on Aug 15, 2012 at 16:12 UTC||Need Help??|
/me nods vigorously ...
I very vividly remember the first time I really embraced unit testing and validation testing as an integral part of the development process. I was writing a set of classes which had to operate smoothly, both within a Mojolicious-based web site, and outside of it. And, this time, I decided to build with tests at every step. I decided not only to test the code’s behavior in normal cases, but its detection of error cases, as well.
O_o !! !! !!
First off, I was amazed at how bad each iteration of the code actually turned out to be when I put it to the test. I discovered errors in my code and errors in my thinking. It was like pulling back the covers of a nice warm cuddly bed and finding bed-bugs everywhere. Ewwwwwwww....! But even more surprisingly, as I built the application piece by piece and constantly ran and re-ran the tests while doing so, I was confronted with how slight of a change can cause functionality that had been working perfectly for weeks, to now break in subtle and unexpected ways.
But I persevered, and here’s what the outcome turned out to be: bulletproof code; a robust web-site; back-end code whose results matched it exactly (after it quit throwing all those exceptions ... all of which I unfortunately knew to be valid throws). I could walk anywhere on that platform; hell, I could dance on it and it wouldn’t break. During debugging I could quickly zero-in on a problem because I knew that the problem could not be here, here, or there.
I wound up building Test::Most tests for the interior and Selenium tests for the user interface (using every browser imaginable). It was hell-on-wheels to get everything to run clean, but when it finally did, it was able to deploy into production with virtually zero defects. Yes, it took considerably longer than I had thought it would, but in retrospect I realize that I really didn’t know, all things properly considered, how long it would take. Furthermore, when the code was done, it was “Big-D” Done. As in, “done for good... really.”
This immediately became our standard business practice, and it has both cut costs and improved customer satisfaction. We frankly had not realized how much profit was “slipping through our fingers” in post-deployment service issues.
We owe a big debt of gratitude to the fact that CPAN modules are accompanied by all those hundreds of tests and won’t install without them. Apply the same principles to your own code. You’ll work a lot harder up front, and get a lot better outcomes in the end.