![[FSF Associate Member]](http://www.notsosoft.net/images/getButton){kind=small}
Why Perl is Ideal for All of Your Automated Testing (1 of 4)
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.
Popularity: 17%
This entry was posted
on Tuesday, April 3rd, 2007 at 15:43 and is filed under Free Software, Hacking, Ranting.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Stumble it!
Why perl is ideal for NO automated testing reason #1:
No support for exception handling. tcl is better automated testing than perl. Python is better than both of them. Take a look at dogtail.
http://www.redhat.com/magazine/020jun06/features/dogtail/
http://people.redhat.com/zcerza/dogtail/
Jeff Schroeder: Really? I use exception handling in Perl all the time. This is news to me.
I didn’t write this post to put others and their work down, and I would really appreciate it if you would have the same professionalism. Thanks.
“Automated testing should run quickly”. I fully agree, however I’d like to know how to achieve that.
When you start a project, the test suite is small and fast. However, as the code grows you write new tests. Eventually the the test suite starts to take tens of minutes, if not hours.
What’s the solution? Get rid or disable old tests? Try to optimize the test suite?
Marius Gedminas: Excellent question! There are a couple of ways that I have noticed people can speed up their automated tests…
1) Use fixtures 100% of the time. Fixtures in this context would be objects or data structures and code that will act like dependencies that aren’t really pertinent to the test itself, but are required for the code being tested. An example here would be that if you’re testing a login routine, a valid user object is all that is necessary. It’s not needed to go to /etc/passwd or your database to fetch it. A static value in memory is all that is really needed. A fixture would provide just this and nothing more.
2) Make your tests compartmentalized and isolated so that you can run them separately from one another. If you just need to verify that you didn’t break your login routine, you don’t need to test your FTP or email routines as well. Continuous testing is a good thing, and those will always tend to slow down with time, but if your tests are compartmentalized then you’ll be able to speed up manual execution of automated tests still.
I know those were long explanations and if you want me to go into any single one of them more, let me know and I’ll be happy to elaborate.