Unit Tests
Earlier this week at Passageways we added a new member to the development team, Rajini. She joins us from the great [big] state of Texas and will be working as our new Quality Assurance person. But since it's been about six months since we had a dedicated QA, the developers started to take matters into their own hands *cue scary 1950's horror music*!
It's not really all that scary, and the solution we came up with makes for higher quality code both short term and in the long term when doing regression testing. What we've added is unit testing. In the past we've done manual testing exclusively, meaning we have a slightly glorified MS Word Document and a tester reads the instructions as she follows along clicking around the portal. These still work great and we haven't abandoned them. The unit test is different because it can be automated, and thus doesn't require a human to be present.
At the moment we're utilizing the unit test feature of VisualStudio 2005 Team Edition. I like it a lot because it integrates nicely with my developer environment. I can attach to the asp.net process and use line breaks to see what's going on in the test and if my newly written code is going to pass or not. What's frustrating is that I can't get it to automatically attach when I run the tests in debug mode, so I have to be quick. Also, if I bail out of a debugged test half way, then I have to go clean up my web.config file so that I can run the tests again. So it's not without its own share of wonkiness, but nothing that can't be overcome by a little practice.
I will also add that unit tests, while still in the tedious category, are a lot more fun to write as a developer than a long step-by-step word document because it's actually code. Presently, we're using the unit tests to check input and output of methods relating to the API, so basically the public methods that ya'll can hook in to - yes, I said "ya'll". Side-effects of methods (such as changing an object property, interacting with the file system) are still being tested via manual tests.
Side-effects of working as an employee at Passageways are still untested, but seems to result in high intakes of caffeine ;-)
It's not really all that scary, and the solution we came up with makes for higher quality code both short term and in the long term when doing regression testing. What we've added is unit testing. In the past we've done manual testing exclusively, meaning we have a slightly glorified MS Word Document and a tester reads the instructions as she follows along clicking around the portal. These still work great and we haven't abandoned them. The unit test is different because it can be automated, and thus doesn't require a human to be present.
At the moment we're utilizing the unit test feature of VisualStudio 2005 Team Edition. I like it a lot because it integrates nicely with my developer environment. I can attach to the asp.net process and use line breaks to see what's going on in the test and if my newly written code is going to pass or not. What's frustrating is that I can't get it to automatically attach when I run the tests in debug mode, so I have to be quick. Also, if I bail out of a debugged test half way, then I have to go clean up my web.config file so that I can run the tests again. So it's not without its own share of wonkiness, but nothing that can't be overcome by a little practice.
I will also add that unit tests, while still in the tedious category, are a lot more fun to write as a developer than a long step-by-step word document because it's actually code. Presently, we're using the unit tests to check input and output of methods relating to the API, so basically the public methods that ya'll can hook in to - yes, I said "ya'll". Side-effects of methods (such as changing an object property, interacting with the file system) are still being tested via manual tests.
Side-effects of working as an employee at Passageways are still untested, but seems to result in high intakes of caffeine ;-)
0 Comments:
Post a Comment
Links to this post:
Create a Link
<< Home