Unit testing built-in functions

aijin has asked for the wisdom of the Perl Monks concerning the following question:

We've started doing test-driven development at my office, and that means writing lots of unit tests.

My current task involves taking a bunch of pre-existing, scattered code and turning it into a module.

There are a lot of built-in calls in the code, and I'm not sure how to tackle them in the unit tests.

For example, for a call like this:

unlink( $filename );
[download]

I would like to be able to have that call fail on a file that should be there, but isn't...as if someone had deleted the file while the program was running. Or perhaps it exists, but can't be deleted.

I am familiar with Test::MockModule and Test::MockObject and was hoping that there was a module that mocked built-in calls so that I could manipulate them in the same way. So far, my search-fu has failed me and I can not find such a module.

Likely, I am missing an obvious solution. Would someone care to enlighten me?

Comment on Unit testing built-in functions Download Code

Replies are listed 'Best First'.
Re: Unit testing built-in functions by perrin (Chancellor) on Nov 08, 2006 at 23:30 UTC
Overriding built-in functions is a FAQ.	[reply]
Re: Unit testing built-in functions by ikegami (Patriarch) on Nov 09, 2006 at 00:33 UTC
You can only override some builtins, and those you can override must be overridden by importing the replacement functions from another module. `>type TestHarness.pm` `use strict; use warnings; package TestHarness; BEGIN { our @EXPORT_OK = qw( unlink ); require Exporter; *import = \&Exporter::import; } sub unlink { print("PRE unlink\n"); # Don't forget to properly handle context. my $rv = unlink(@_); print("POST unlink\n"); return $rv; } 1;` [download] `>type test.pl` `use strict; use warnings; BEGIN { # Parse options or something. $::TESTING = 1; } use if $::TESTING, TestHarness => qw( unlink ); unlink();` [download] `>perl test.pl` `PRE unlink POST unlink` [download] You could control `TestHarness::unlink`'s behaviour using globals.	[reply] [d/l] [select]
Re^2: Unit testing built-in functions by Sidhekin (Priest) on Nov 09, 2006 at 01:06 UTC
You can only override some builtins, and those you can override must be overridden by importing the replacement functions from another module. The former: Yes. The latter: Um, no. Or at least, not quite: `~$ perl -le 'BEGIN { CORE::GLOBAL::unlink = sub(@) { print "@_" } } u +nlink "aaa".."aad"' aaa aab aac aad` [download] `print "Just another Perl ${\(trickster and hacker)},"` The Sidhekin proves* Sidhe did it!	[reply] [d/l] [select]
Re: Unit testing built-in functions by davidrw (Prior) on Nov 08, 2006 at 23:12 UTC
per perldoc for unlink, it returns the number of files deleted .. so can you just change the calls to something like this? `if( unlink( $filename ) != 1 ){ die "couldn't unlink '$filename': $!; } # or: unlink( $filename ) or die "couldn't unlink '$filename': $!;` [download] Your unit tests could also check for both the existance before the unlink, and non-existence afterward ...	[reply] [d/l]
Re^2: Unit testing built-in functions by ikegami (Patriarch) on Nov 09, 2006 at 00:01 UTC
I believe you misunderstood. The OP wants to override `unlink` so he can test how the script handles errors from `unlink`. He's not asking how to check if `unlink` returned an error. We do something similar at my workplace. In our test environment, we hook into the OS to control the exit codes returned by the disk reading function, the analog input reading function, the analog output writing function, etc. to ensure that our software properly handles those errors.	[reply] [d/l] [select]
Re^3: Unit testing built-in functions by aijin (Monk) on Nov 09, 2006 at 01:07 UTC
Yes, exactly. I want to get built-in functions to return specific values when called from specific test cases. It looks like over-rides and globals will be the easiest way to go so far.	[reply]
Re: Unit testing built-in functions by sgifford (Prior) on Nov 09, 2006 at 04:02 UTC
Maybe this is a silly question, but why not just create/delete the appropriate file in the test setup, probably in a temporary directory, then check to make sure it's been deleted? Obviously it's a little more complicated than that, but it doesn't seem a lot more complicated... -- sgifford's Web page	[reply]
Re^2: Unit testing built-in functions by f00li5h (Chaplain) on Nov 09, 2006 at 08:44 UTC
The reason you don't want to be manipulating the file system and/or database to set up your test cases is that you have to know a lot more about what's inside the code you're testing if you do that, you need to know that the module is going to go looking for a particular file, which file, what it will try to do to the file. (and if the system is written by monkeys who dont know<rant removed> like at $job, there will be hard coded paths, special cases, things that should be cleaned up but aren't... Also, if you can just automatically fail to remove the file (as per a mocked unlink) your tests will run a bundle faster, and you will be able to run the tests on production without having to worry (since it won't be axing the file your batch process just spent hours creating) And, with a mocked unlink, you can be sure that it's trying to remove the right file ie that the call `unlink $file` has the right thing in `$file` and you can trigger pass/fail based on that `@_=qw/ ask foolish to appear and remain for a moment _ of pretend better than a lifetime /; s;;@{[map{$_[hex$_]}split'',C204316E89D2B4516EF]};;s/_ /\n/&print;` [download]	[reply] [d/l] [select]