Ok, now that I understand what library you're using ...
On Fri, Jun 25, 2004 at 04:41:15PM +0100, Tony Bowden wrote:
> On Fri, Jun 25, 2004 at 11:10:19AM -0400, Andrew Pimlott wrote:
> > I was responding to your suggestion to put all the tests in one method
> > if they are just parametrized by data. How do you suggest writing the
> > equivalent of
> > foreach (@test_data) {
> > is(my_func($_->{input}), $_->{output}, $_->{test_name});
> > }
> > in xUnit style, such that the first failure does not cause the rest not
> > to run?
>
> erm,
>
> sub test_my_func : Test(no_plan) {
> my $self = shift;
> my @test_data = get_test_data_from_somewhere();
> $self->num_tests(scalar @test_data);
> foreach (@test_data) {
> is(my_func($_->{input}), $_->{output}, $_->{test_name});
> }
> }
By not using the failure == exception part of the xUnit model, you avoid
the issue I was getting at. Obviously, the above would stop after the
first test data that provokes a failure if you were using that model,
which is why I consider it limiting.
You are also circumventing the isolation part of the xUnit model,
because you don't get setup/teardown for each test data. Possibly you
don't care about that in this case, but if you did, you wouldn't be able
to do the above, so I consider this another limitation.
So to me, the above code is basically Test::More style, just using
methods for organization. On that note, it seems that for some people
the appeal of xUnit-style testing is less the model above (failure ==
exception, isolation), and more the modularity and reuse you can get by
writing your tests with objects. On this point there's not much to
argue about--if that helps you write better tests, great!
Which leaves me wondering if anyone defends Test::Unit per se. :-)
Andrew
