Re: [Perlunit-devel] Towards Version 1.0

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

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

> Piers Cawley (pdc...@bo...) wrote:
>> And, dammit, the framework is really useful now and creeping towards
>> maturity. I'm thinking of picking the current trunk (with a working
>> 'ok')  and tagging it 1_0_RELEASE_CANDIDATE freezing the features,
>> hammering on it to make it work with 5.7.2, writing a quick tutorial
>> pointing people at Test::Unit::TestCase and getting it up to CPAN as
>> 1.0 as soon as we're happy with it. The Roadmap for this, as I see it
>> is:
>> 
>> 1. Rename Test::Unit to Test::Unit::Procedural
>> 2. Rename Test::Unit::HarnessUnit and Test::Unit::UnitHarness
>>    Not sure what to yet, but I want to get these big API changes out
>>    of the way before we bump the version number.
>> 3. Working ok
>> 4. Working build on 5.7.2
>   5. Change suite-building API so that MySuite really ISA TestSuite,
>      and gets instantiated via new() rather than the current suite()
>      nonsense.  This is a *big* API change, but I'm utterly convinced
>      we need to do it.  I think it should be possible to keep
>      backwards compatibility, however.

Ooh yes. Definitely necessary.

>   6. If a testcase fails compilation, you currently get `Suite class
>      MyTests::Foo not found', rather than `Failed to load ...'; this
>      needs fixing.

Yup. Actually, I *think* I may have fixed that en passant. It's to do
with TU::Loader not remembering the *initial* $@ when it goes off
trying to load the class via various methods. I sometimes wonder if
we're not trying to be 'too friendly' at this point.

>   7. Stop `make test' failing when DEBUG is enabled?

Yeah, definitely a good idea.

>   8. Move test libraries out of lib/Test/Unit/tests.

Ooh yes. Very important that one.

>   9. Deal with broken base.pm in older Perls (or we could always be
>      nasty and stop supporting < 5.6, best to avoid if we can
>      though).

I love the thought of being nasty, but this doesn't seem to be a good
enough reason to break the backwards compatibility that hard. 

> None of these are big jobs, but I think they should all be done
> before 1.0 if we want the framework to gain respect and widespread
> usage; after all, many people will check out PerlUnit for the first
> time when they hear 1.0 being announced, and first impressions count
> for a lot.

Indeed. I'm already thinking of wording the announcement as well. I
want to steal some mindshare back from Test::More and its brothers.

>> Nice to have
>> 
>> 1. Test::Unit::Loader working with whole directories.
>> 2. <YOUR SUGGESTIONS HERE>
> 
>   2. Refactoring of runner classes to allow storing state in the
>      runner.  This paves the way for choosing which tests to skip in a
>      given run, which brings me on to ...

I'm not sure this isn't a 1.1 feature though.

>   3. Test filtering.  I like your Attribute::Handlers idea a lot, and
>      have a very real need for decent filtering right now.

Ah yes. This may well be a good reason for breaking backward
compatibility with earlier Perls. I can't remember what the minimum is
for Attribute::Handlersx

>   3. Rethink how the tests are split up between the t/*.t.  Currently
>      we have t/all_tests.t, which is clearly a misnomer, and we have
>      some tests for the assertion code being run from that rather than
>      from t/assert.t.

Personally I don't like all_tests.t for running in 'Test::Harness'
style. It's great to be able to do TestRunner.pl tests::all_tests if
you're working in an xUnit style, but breaking things up so that 'make
test' gives people the output they expect seems like a win to me.

It'd be *really* nice if we could do the following in foo.t

    package test::foo

    # Define some tests for this package.

    unless (caller) {
        require Test::Unit::SelfRunner;
        Test::Unit::SelfRunner->run;
    }

Which might be surprisingly easy to push in for 1.0

While I'm about it, having a 'Runner::new' that took an argument
specifying which display style to use would be nice... Get it right
and you can have it looking at ~/.perlunitrc to select the users
preference. This is probably post 1.0 though.

> Some of these could be left until after 1.0; however given that I will
> certainly be aiming to commit some of them very soon (today, tomorrow
> ...), it's probably more hassle than it's worth branching off for the
> release straight away.
> 
> I'll commit all these to doc/TODO now, and then we can twiddle with it
> as need be.

Sounds like a plan.

> Incidentally, we must remember to consult doc/release-checklist before
> making a release ...

Indeed. And I need to work out how to convince PAUSE that I'm the
maintainer now...

-- 
Piers

-- 
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?