Okay, so I know some jive-turkeys have been talking some serious smack about Perl, and you may even be one of them (if so, you’re a jive-turkey). Here I will attempt to show you how Perl could meet your needs in testing ANY application, in ANY language, in ANY environment, regardless whether or not your program is written for command-line interaction, GUI interaction, or web interaction. That’s quite a claim, no? Well I can totally prove it!
This will be a four-part series on manchicken’s automated testing theory, using Perl. This first installment defines what automated testing should and should not be. Next we will break down into three different posts on how Perl is ideal for unit-level testing, then integration-level testing, finishing up with user-interface-level testing. As always, feel free to link, comment, complain, etc. Try to stay on topic though. Thanks.
What is automated testing?Quick rant on automated testing
Okay, so a lot of you know that I like automated testing. I just wanted to get a few things across before I start making points beyond this. Here are my stances on automated testing:
- Automated testing should be done before code is written, and updated during the whole life of the code.
- Automated testing should run quickly, and be safe to run on both development and production environments.
- Automated testing should not require human interaction beyond the preparation for a run and then firing off test run… until it is done of course.
- Automated testing does not eliminate quality assurance personnel or the job they do. It merely changes them to finding new problems and designing tests rather than spending oodles of time regression-testing.
- Automated testing should be controlled experiments. This means it should be done the same way every time. No random data patterns, no assumptions, no pulling from external databases. Fixtures help here.
- Automated testing should be at various levels: code-unit (object or function level), library functionality integration level, and user-interface level.
- Automated testing should make the developer’s life easier as well as the QA engineer’s life.
- When reading automated tests, the test plan should be obvious.
- In automated testing, hard-coding data is not a bad thing.