Re: [Perlunit-devel] (no subject)

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> 
> > Is lib/Test/Unit/tests/TestAssertionCodeRef.pm dead?  It doesn't
> > currently seem to be used.  We also seem to be missing tests for
> > Assertion::Regexp and Assertion::CodeRef; I'll add those to
> > tests/AssertTest.pm along with new tests for the finished ok()
> > wrapper.
> 
> I think I wrote it to help with the development and didn't get 'round
> to adding it to AllTests.

Ah.  Are you going to resurrect it?  I didn't understand
test_case_to_string at all, nor the

  $self->assert(qr/bar/, 'foo');

bit :-)

> BTW, I've been thinking about the naming and placing of test packages.
> 
> 1. By placing the tests in the ./lib tree they get installed along
>    with the rest of the testsuite. I'm not sure that this is a good
>    thing.

You're right, it's not.

> 2. I've taken to naming my test classes using the same 'lower case
>    with underscores' approach as that used for method names etc. This
>    may not be a desperately good naming strategy, but it does help to
>    distinguish tests from operational code.

Sounds reasonable.

> 3. On preface (the refactoring engine), I've taken to placing tests in
>    a tlib directory. This has the advantage of not having tests
>    installed and lets you use shorter names for your test libraries:
> 
>    test::assertion_coderefs instead of
>    Test::Unit::tests::TestAssertionCodeRef
> 
>    If we were to write a 'tlib.pm' modelled on blib.pm we could make
>    working with a test libs directory reasonably trivial for
>    developers. 

A nice idea, but surely this wheel has already been invented in some
way?  Why not just do something idiotically simple like sticking the
test libraries in the `t' directory, and then put

  use lib 't';

in your t/*.t?  (Or better, hack Makefile.PL, or god forbid,
ExtUtils::Makemaker, so that a `make test' includes -It as an option
when running the tests.)