Re: Unit testing built-in functions

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

Comment on Re: Unit testing built-in functions

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]