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.
December 2013 Archives
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.
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.
Test::Class, this means using separate
*.t tests for every test class versus using a single
*.t test and
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.
Not Perl related, but I suspect some folks may appreciate this.
Today after a nasty mistake on the command line involving
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!