Re: [Perlunit-devel] (no subject)

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> 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 :-)

Well, it's gonna fail isn't it. I'll take a look at the code when I
get some time. Must write rigged demo for the refactoring engine first
or I'm going to look very silly at the London.pm tech meet...

>> 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.)

Well, it's sort of dependent on where you run the script from.
Actually I'm more inclined to stick the *modules* in t/tlib (I'll
explain why it has to be tlib in a minute) and then do 

    use lib 't/tlib', 'tlib';

So that you can run the tests from either the project root or from
inside the t directory. It has to be tlib instead of lib to avoid
using the files in lib/* rather than blib/*.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?