Adam Spiers <[EMAIL PROTECTED]> writes:
> Piers Cawley ([EMAIL PROTECTED]) 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?
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/perlunit-devel
