--- On Fri, 2/4/10, Erik Osheim <e...@plastic-idolatry.com> wrote:

> From: Erik Osheim <e...@plastic-idolatry.com>

> > I assume either
> some code builds it
> > and others then need it or it's expensive to
> build?  If it's the
> > former, it implies an ordering dependency and coupling
> in your tests
> > which greatly lowers their utility.
> 
> It's more the former than the latter, and yes, it does
> lower the tests'
> utility.

Ouch. On the other hand, plenty of legacy systems get created this way :)

> The application suffers from its monolithic
> architecture. We
> had previously tried to use mock objects to do all the
> testing but most
> of the mock objects ended up needing to be "close enough"
> to the real
> thing to defeat the purpose.

I've never been a fan of mock objects.  If your interface changes but you've 
mocked it up, your tests can generate false positives.  For that matter, it's 
why I lean towards integration tests over unit tests (there are trade-offs, of 
course).

> Maybe I should port my solution to Test::Class and write
> something
> similar to Test::Class::Load (maybe called
> Test::Class::Dependency) to
> manage the automatic loading of dependent classes (e.g. for
> test D,
> load tests A and B automatically and make sure to run them
> first)? Or
> do you think I should stick with my custom solution?

Actually, I'd love to see a patch to Test::Class which adds "tags" to test 
methods.  Imagine this:

    sub customer_order : Tests(23) Tags(Customer Order) {
        my $test     = shift;
        my $customer = $test->test_customer;
        ok $customer->login, '...';
        ...
    }

The idea behind a 'tag' is that your test framework can spot it and take action 
accordingly.  In the example above, your "setup" method might look like this:

    sub setup : Tests(setup) {
        my $test = shift;
        foreach my $tag ( $test->test_tags ) {
            # or whatever code you need
            $test->load_fixture($tag);
        }
    }

By being able to tag tests, you'd be able to:

* Load fixtures as needed.
* Load dependencies as needed.
* Run only '$tag' tests
* ... or anything else you can think of with tags

Yeah, I know it would be more work for you, but you'd really help those who use 
Test::Class and want more out of it :)

If you're struggling with Test::Class, I have a tutorial at:

    http://www.slideshare.net/Ovid/testing-with-testclass

Cheers,
Ovid
--
Buy the book         - http://www.oreilly.com/catalog/perlhks/
Tech blog            - http://blogs.perl.org/users/ovid/
Twitter              - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Reply via email to