On Sat, Aug 02, 2003 at 12:09:22AM +0100, Adrian Howard wrote:
> -     Rather than running tests at live time, I'm more often doing the 
> opposite. I have assertions that I only want to switch on at testing 
> time since that is when I'm exercising things that might break.
> 
> -     This sort of thing always makes me think of things 
> design-by-contract... I'm sure there is some useful intersection 
> between automated tests and DBC - but I've yet to feel bright enough to 
> work it out.

For my next trick...  

Class::Contract has always bothered me as way too much Kool-Aid to 
drink in one sitting.  Cutting DBC down to its Best Trick: inheritable
invariants.  And an invariant is just a test before or after a function
call.  All the rest of Class::Contract, the enforcement, the new OO syntax...
that can all be thrown out.  If you want all that, use a different module.

So what you're left with is...

    use Test::Contract;
    use Test::More;

    sub add {
        pre { is( @_, 2, 'got two arguments' ) }

        my $sum = $_[0] + $_[1];
        return $sum;
        
        post { unlike( $ret, qr/\D/ ) }
    }

...and the rest is a little clever filtering.

Ooooh!  I just had a great idea.  Use "TEST { ... }" instead of "TEST: { ... }"
in Test::AtRuntime.  If the user has Filter::Simple, use that to strip out
the TEST blocks.  Otherwise, its a function call to TEST() passing in a code
ref which it would run or not run based on if we're testing or not.  Except
now there's a dependency on Sub::Uplevel. :(


> -     I think the idea of being able to run tests as assertions is a cute 
> one worth exploring. Just having a T::B subclass that died rather than 
> log anything would be a boon. Giving us all the goodness of the T::B 
> based functions for normal assertions.

Carp::Assert::More.  Or even more trivially, take Test::AtRuntime and swap 
out Test::Builder::ok() with something that dies on failure.


> -     You'd probably want an option to pop a stack trace next to the test 
> output (maybe only for failing tests?)

Definately only for failing tests.  Good idea, though.


> -     Option just to log failing tests might be useful?

Yep, that's in the todo.


-- 
Here's hoping you don't become a robot!

Reply via email to