December 2013 Archives

Eating my own dogfood (parallel tests)

I'm relatively pleased with my work in creating parallel testing with Test::Class::Moose, but I wanted to make sure that it worked with a real world example, so today I took a small, but real test suite and converted it and tried out my parallel testing code. The results were interesting.

Merry Christmas! Parallel testing with Test::Class::Moose has arrived

You'll want to checkout the forks branch to see it in action. Read the docs for Test::Class::Moose::Role::Parallel to see how to use it (you'll probably need to create your own schedule).

What follows is a very naïve benchmark where I reduced a 12 minute test suite down to 30 seconds.

Accidentally duplicating tests with Test::Class

Imagine you open up a test file and you see the following:

is foobar(3), 17, 'foobar(3) should return 17';
is foobar(2), 15, 'foobar(2) should return 15';
is foobar(3), 17, 'foobar(3) should return 17';   # duplicate?
is foobar(4), 20, 'foobar(4) should return 20';
is foobar(3), 17, 'foobar(3) should return 17';   # duplicate?

Well, that looks strange and duplicated tests are a code smell. However, it could be a code smell in one of two ways. It's probably the case that some programmer got sloppy and duplicated the tests so do you delete the extra tests?

Of course not! You're an experienced programmer and you've learned to look both ways before crossing a one-way street. Maybe foobar() uses state variables to cache results and caching can sometimes go awry. Or maybe that function connects to an external service. Or maybe there's a rand() tossed in there just for fun. Who knows? If there is a reason those tests should be duplicated, we probably have bad test descriptions and we should rewrite the descriptions so that future programmers will understand why we have duplicated tests.

So you inspect the function and you determine that, yep, the tests are duplicated and should be deleted.

If you use Test::Class or related modules, appreciate the benefits of test inheritance, and are using separate *.t files for every test class, you're making the same mistake.

Follow Ovid on twitter

Just checking to see if this works.

Single process versus parallel tests

Whenever I present a talk on Test::Class or one of its variants, invariably someone asks me about parallelization. The reason is simple: I advocate running your xUnit tests in a single process instead of multiple processes, but it's hard to run tests in parallel when they're already forced into a single process.

For Test::Class, this means using separate *.t tests for every test class versus using a single *.t test and Test::Class::Load.

I am working on making parallel tests possible with Test::Class::Moose, and while I have test classes running in parallel, the confused is output (yes, that was deliberate). I know how to solve this using only publicly exposed APIs, but there are some tricky bits. I thought about asking for a TPF grant, but since most don't use xUnit style testing, the value seems marginal. Plus, I am on the Board of Directors for the Perl Foundation and that can look like a conflict of interest. Hence, my slow work in this area.

That being said, it's worth doing the math and asking ourselves where we get the greatest gain.

Showing Hidden Files on OS X and Time Machine

Not Perl related, but I suspect some folks may appreciate this.

Today after a nasty mistake on the command line involving find and rm, I discovered that I deleted a number of files I didn't mean to delete, including some hidden files. Oops! I opened my Time Machine backup, only to discover that it doesn't show hidden files. However, it turns out that you can use that to show hidden files so long as your main system shows hidden files. I'm using OS X Mavericks, so I dropped the following bash script into my bin folder and named it togglehidden. Running this from the command line will toggle showing hidden files in the Finder on or off.

#!/bin/bash

is_shown=$(defaults read com.apple.finder AppleShowAllFiles)
if [ $is_shown != "TRUE" ]; then
    echo Showing hidden files
    defaults write com.apple.finder AppleShowAllFiles TRUE
else
    echo Hiding hidden files
    defaults write com.apple.finder AppleShowAllFiles FALSE
fi
killall Finder

Use at your own risk!

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/