Re: Unit Testing in Perl

Is there any real consensus in the Perl community with respect to how unit testing ought to be done?

"Ought to be done" conflates two separate ideas: The first is the approach one takes to unit testing (e.g., TDD with or without mock objects, test-specific subclasses, etc.). Since the choice of approach is best dictated by the thing you're trying to build, and we're all building different things (albeit with some common themes), consensus here on a single approach is unlikely.

The second idea is about the specific testing tool or framework. A lot of unit testing in the non-Perl world uses some variant of xUnit, though the use of the tool may be less interesting than the choice of whether to mock, subclass, or whatever.

Which module, were I to use it, would cause the least scoffing from those in the know when it comes to unit testing Perl code?

I think you'll find that the scaffolding depends more on what you're trying to test than it does on your choice of testing framework. Test::More is a decent starting point. At work we use a custom subclass of Test which we're reasonably happy with. (And we have >12,000 unit tests.)

The fact that there is no well accepted standard is quite discouraging. Said lack makes it very difficult to do integration testing across modules, unless you could at least get everyone to agree to a common harness.

You're apparently seeing a problem here that I'm not. What do you mean by "integration across modules", and how does that vision depend on having a single test harness?

Edited to add: The part I find disappointing is that unit testing still isn't widely used.

Comment on Re: Unit Testing in Perl

Replies are listed 'Best First'.
Re^2: Unit Testing in Perl by skyknight (Hermit) on Jun 26, 2005 at 13:26 UTC
Well, the kind of problem to which I was alluding is that to which mosquito refers to here. And yes, it is extremely disappointing that so many people set about writing code without a formalized process for doing automated tests. I just finished graduate school and started a new job. On Friday I was introduced to an enormous blob of Perl code, entirely functional, completely undocumented, devoid of unit tests, and with data hard coded into it. I'm trying to figure out how best to suggest that I ought to be allowed to rewrite the thing. Perhaps I ought to suggest first that in order to learn how it works that I write some tests for it, and perhaps write some documentation as I figure out stuff, a Stone Soup strategy if you will. Oh, and did I mention that it's not in version control? The guy who developed it just takes occasional snapshots of the code. So, basically I'm trying to figure out how to hijack this project and set it right, all without stepping on anyone's toes. I've got my work cut out for me... Or maybe I should just steer clear of it and work on something of my own from scratch. I seem to have a lot of flexibility in that regard, as developers in this group are basically just set free to find interesting problems to tackle. Maybe it'd be better to just lead by example than to try to beat a pre-existing project into good shape. I don't know... Entering a new group is a tricky and delicate process. I'm starting to feel that it is my lot in life to be a Jonny Appleseed of the software development world.	[reply]
Re^3: Unit Testing in Perl by dws (Chancellor) on Jun 26, 2005 at 15:37 UTC
So, basically I'm trying to figure out how to hijack this project and set it right, all without stepping on anyone's toes. "Draining the swamp" problems are fun, especially when there are people still living in the swamp. If you're starting from zero (tests), I'd suggest starting with strictly functional ones. If it's a web app, reach for WWW::Mechanize and Test::More (or Test::WWW::Mechanize, which I haven't used yet but am told is worth the effort), and figure out how to write functional tests that drive the application through various scenarios. If you're not dealing with a web app, the idea is the same. Then, when you go on a cleanup binge, start by writing functional tests to cover what you're about to change, then see if you can get under the covers, isolate the code you're working with, and write some unit tests for it. The combination of functional and unit tests will give you some comfort as you restructure and refactor. If the swamp dwellers don't want you writing unit tests, and won't be led gently in that direction, staying at the functional level is better than nothing.	[reply]
Re^3: Unit Testing in Perl by eyepopslikeamosquito (Archbishop) on Jun 26, 2005 at 21:53 UTC
On Friday I was introduced to an enormous blob of Perl code, entirely functional, completely undocumented, devoid of unit tests, and with data hard coded into it. Then these nodes may be of interest: Becoming familiar with a too-big codebase? Analyzing large Perl code base. What is the best way to add tests to existing code?	[reply]
Re^3: Unit Testing in Perl by adrianh (Chancellor) on Jun 27, 2005 at 01:00 UTC
Friday I was introduced to an enormous blob of Perl code, entirely functional, completely undocumented, devoid of unit tests, and with data hard coded into it. I'm trying to figure out how best to suggest that I ought to be allowed to rewrite the thing. If you don't already have a copy go get Perl Medic. Lots of useful tips for attacking this sort of evil task.	[reply]


XP is just a number
	PerlMonks