* David Golden <[email protected]> [2009-06-30T14:46:47]
> Well, if you're doing interface design, one of the first things that
> comes to mind is that the name of the test should come first, not
> last.
...I basically liked everything you had to say here:
> test "label goes here" => is( $have, $want ) => diag $diag;
> test "a subtest label" => nest { [ ... } ]
> test "label" => is( $have, $want ) => setup \&setup => teardown
> \&teardown => diag \&diag => note \¬e;
So, &test is a fixture that expects to be handed:
* an assertion, required
* optionally a bunch of other components
... and it knows how to assemble components and execute them.
I really like this. You can add more known components as time goes on. You
can make new fixtures that do things differently. You could import a foo-style
one here and a bar-style one there, each called test, or you could mix and
match by renaming them:
(foo.t)
use Tester::Fooish;
test ...;
(bar.t)
use Tester::Barish;
test ...;
(baz.t)
use Tester::Fooish test => { -as => 'test_foo' };
use Tester::Barish test => { -as => 'test_bar' };
test_foo ...;
test_bar ...;
...so there's not much penalty for getting the specifics wrong to start with.
Since components just perform some known role, Fooish and Barish can both
expect a Tester::Diagnostic, but only Fooish wants a Tester::Metafixation. And
so on.
I am excited by this idea.
--
rjbs
