Comments on: Why Perl is Ideal for All of Your Automated Testing (1 of 4) http://www.manchicken.com/2007/hacking/why-perl-is-ideal-for-all-of-your-automated-testing-1-of-4.html Rantings of a Questionably Sane Chicken Fri, 21 Nov 2008 10:59:59 +0000 http://wordpress.org/?v=2.6 By: manchicken http://www.manchicken.com/2007/hacking/why-perl-is-ideal-for-all-of-your-automated-testing-1-of-4.html#comment-259 manchicken Thu, 05 Apr 2007 01:06:39 +0000 http://blog.notsosoft.net/2007/hacking/why-perl-is-ideal-for-all-of-your-automated-testing-1-of-4.html#comment-259 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. 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.

]]> By: Marius Gedminas http://www.manchicken.com/2007/hacking/why-perl-is-ideal-for-all-of-your-automated-testing-1-of-4.html#comment-258 Marius Gedminas Wed, 04 Apr 2007 14:29:03 +0000 http://blog.notsosoft.net/2007/hacking/why-perl-is-ideal-for-all-of-your-automated-testing-1-of-4.html#comment-258 "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? “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?

]]> By: manchicken http://www.manchicken.com/2007/hacking/why-perl-is-ideal-for-all-of-your-automated-testing-1-of-4.html#comment-255 manchicken Wed, 04 Apr 2007 01:25:09 +0000 http://blog.notsosoft.net/2007/hacking/why-perl-is-ideal-for-all-of-your-automated-testing-1-of-4.html#comment-255 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. 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.

]]> By: Jeff Schroeder http://www.manchicken.com/2007/hacking/why-perl-is-ideal-for-all-of-your-automated-testing-1-of-4.html#comment-254 Jeff Schroeder Tue, 03 Apr 2007 23:33:02 +0000 http://blog.notsosoft.net/2007/hacking/why-perl-is-ideal-for-all-of-your-automated-testing-1-of-4.html#comment-254 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/ 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/

]]>