Running your Perl tests in Eclipse

May 19th, 2009 by iain

As I keep dropping to a shell to run my tests I couldn’t help wonder if there was a way I could run them from my eclipse session. Of course you can, and its easy (I’m assuming Linux here):

So what I want to do is replicate this command in eclipse

prove -Ilib t/01_test.t

First setup an external tool: Run –>External Tools–>External Tools Configurations. You should see the following screen:

external tools configurations

Right click the Program entry and choose New (if you dont see the Ant and program entries check the filters). You should now see the External Tool Configurations screen.

externaltoolsconfigurationscreen

Location: Set this to the location of prove e.g.

/usr/bin/prove.

Working Directory: To set this to your project directory use the eclipse variable

${project_loc}

This will give you the absolute path to your project directory.

Arguments: This is where we can pass our arguments to prove. As I want to be able to run individual test files I use the eclipse variable ${resource_loc}. This gives me arguments of:

-Ilib ${resource_loc}

externaltoolsbuttonNow click Apply and Close. Select your .t file in the navigator view and click the external tools button

If all has gone well you should now see your test running in a console window at the bottom of your workspace.

If you need environment variables, such as DBIC_TRACE or CATALYST_CONFIG_LOCAL_SUFFIX then you can just add them to the Environment tab in the External Tool Configuration screen.

Happy testing!

p.s. You do write tests don’t you?

Hooked on Perl

April 30th, 2009 by iain

What got me hooked on Perl?

Well rewind a few years to a fresh faced student graduating from university with no real language to call my own.  I moved through the usual suspects VB, ASP, dabbled a bit with C until finally I got my first real job.

After working with VB for a couple of months I got asked to help out with a new project, a funky new XML converter. The traditional route for this company would be to write the converter in C, however somebody had suggested trying out this Perl language as it is supposed to be good with text. So there I was the junior developer pitted against the senior C guy. Thanks to the CPAN  I had a working converter in a surprisingly short amount time. The C guy had barely started.

While I was waiting for the C guy to finish his code I set about hooking my script into apache, no need to write your own preforking  server is there? That didn’t take long so it was onto the load test. This was a disaster. The server couldn’t handle anywhere near the throughput we needed. The C guys nodded “thought as much” and to be honest I had thought this was all to good to be true, but not one to give up I carried on digging and searching.

mod_perl. Its not my fault I hadn’t heard of it before, I was new to this Perl thing. Now that I had a shiny mod_perl server setup it was time to restart the load tests. While not a disaster there was a serious issue with memory use. Again not one to give in easily I did a bit of fine tuning and, more importantly, discovered you can preload modules and get the full benefit of memory sharing.

By this time the C version was ready and the head to head started. To everybody’s surprise, even mine, the Perl running under Apache and mod_perl performed as well as the C version. Different variations of the tests were run but the results were the same.

The benefits of using Perl were clear, I had delivered working code in a fraction of the time to code in C and the performance under load had been so close as not to matter.

My love of Perl had started.