The Programmers’ Revolt
The Programmers’ Revolt
Join the DZone community and get the full member experience.Join For Free
Every once in a while, something happens in life that makes you say, “enough!”
That happened a couple of weeks ago to me and a couple other programmers working on the same project that I’m working on.
The issue was that we had made some significant changes to a project, we had communicated to the project manager that the changes required that the entire project needed to be retested, but the testing never happened. So of course we spent the next several days doing the “testing” and fixing.
This scenario should resonate with just about every programmer that reads this blog, but it should raise some questions as well.
The chief question that has to be raised is, “Why didn’t the programmers test the application?” There are two reasons. The first is, we never felt like we had been given time to test. The second is that we don’t really feel like we understand exactly what the system is supposed to do.
But by not testing at all, the programmers are the ones who pay. And that’s why the revolt took place. We all came to the conclusion independently that since no one else is doing a complete test of the system before it goes to production each week (yes, we make weekly changes) the people who suffer the most are the programmers. Therefore, it makes sense for us to start creating tests for this system that we run the application through prior to calling it “done.” That is, testing is part of programming, not an extra step that we need to have time allocated for or that someone else should be doing.
So we’ve made testing part of the task of programming. It isn’t as glamorous as coding and we won’t catch anything, but catching nothing is better than not even trying. As new bugs surface we will add those conditions to our plan.
Of course, now that we’ve caught on to the testing religion, we need some tools to help us manage things. The last time I implemented testing, I was using Test Complete. This tool allows you to record tests to a script file and then modify the script and play it back. It’s a pretty good tool. The only problem is, you have to learn a new scripting environment and it is pretty expensive. I also find the process of creating scripts tedious. Many times you don’t know how to automate something until you’ve repeated the steps several times so that you can see the commonality of what you are doing each time.
So what we really need to start with is a tool that just allows us to organize and record what needs testing. This is called a test scenario. I searched for a free tool and ended up at the xqual.com site where I found a free java application that is basically a project management system with testing as its center. You should check it out.
As I started thinking through the tests that we needed to run immediately, I realized that one thing we really needed immediately was some way of spidering the site and making sure we don’t end up at a 404 or 500 error page. I had been using iMacros for web process automation, but as a testing platform it falls a bit shy of what we need.
Then I found Selenium, which is a framework for building automated tests in several different environments, including Visual Studio’s MS-Test or NUnit. It didn’t take me long after that to find an NUnit test for Selenium that spiders the web application and makes sure you don’t end up on a 500 error page. I will be embellishing this over time so that it checks each page it lands on for things that must be true on every page.
So now we’ve got something in place that we can add to over time. It’s not perfect, but it is something.
Published at DZone with permission of Dave Bush , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.