Wait just a second.
As far as I'm concerned, I WANT my tests to be right there in my code. Maybe not as the final form in which it will be used, but certainly in the "source source" version.
That's what Test::Inline was written for. Being able to do something like the following is a god-send.
=pod
Document method here
=begin testing
my $Test = Foo::Bar->new('blahblah');
is( $Test->whacko, 1, "'blahblah' new Foo::Bar is whacko" );
=end testing
=cut
sub new {
...
}
The simple script that comes with Test::Inline sucks out the tests, builds it a .t script, and whenever you change the name of a method or the way it works, you can just add tests right there. The test scripts recompile to reflect the change.
I liked this so much I wrote Test::Inline::Heavy ( as yet unreleased ) to add per-method and per-module dependancy-based ordering, and scale it up to handle dozens of classes compiling down to one script per-module.
And it's awesome when building for clients, you can easily maintain vast numbers of tests in-place, written by different people, and when you roll it out to the client you compile the tests to get a single cohesive test directory, and then remove the relevant sections of the pod to help maintain clarity for their QA/debugging people. | [reply]
[d/l] |
If it works for you, that is OK. Everyone's mileage may vary. I'd rather not have my scripts (over)loaded with in place tests, esp. not if they have to be removed later in the final version.
CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
| [reply] |