perlunit-devel Mailing List for PerlUnit (Page 4)
Status: Beta
Brought to you by:
mca1001
Menu
▾
▴
perlunit-devel — PerlUnit development mailing list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(77) |
Dec
(28) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
(1) |
Mar
(13) |
Apr
(1) |
May
(5) |
Jun
(20) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(5) |
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Adam S. <ad...@sp...> - 2001-12-20 20:51:16
|
Think I just found some bad brokenness, although it could be just me
getting hopelessly confused as my brain gets trampled into mush by a
quagmire of exceptions and assertions. I have a testcase:
sub test_this_should_fail {
my $self = shift;
$self->assert(sub { $_[0] eq $_[1] or die "$_[0] ne $_[1]" }, 'a', 'b');
}
which does not fail. In fact it behaves identically to
sub test_this_should_fail {
my $self = shift;
$self->assert(sub { $_[0] eq $_[1] or die "$_[0] ne $_[1]" }, 'a', 'a');
}
Can anyone reproduce with latest CVS?
|
|
From: Adam S. <ad...@sp...> - 2001-12-17 19:56:03
|
Piers Cawley (pdc...@bo...) wrote: > "Hans Donner" <co...@po...> writes: > > Maybe an idea to package a new release before any new stuff is being > > added / refactored? (and with the current speed of changes to do > > this every month or so?) Im following the recent changes with great > > interest, but Im not such a CVS addict to retrieve the latest > > version being developed (currently I havent got the time; I work > > with PerlUnit only at home (my job does not include programming)). > > Good idea. I'll see about packaging up what we have and shoving it on > sourceforge and CPAN. That'd be great. Even if 1.0 doesn't happen this year, much better to have a 0.15 rather than nothing at all. I'd certainly like to see more people trying out my recent changes before we start thinking of a stable release ... I notice doc/release-checklist is slightly out of date, incidentally. |
|
From: Adam S. <ad...@sp...> - 2001-12-17 19:37:35
|
Piers Cawley (pdc...@bo...) wrote: > Matthias Ferber <mf...@hi...> writes: > > On Wed, 12 Dec 2001, Piers Cawley wrote: > >> Diffs would be good. If you start making more and we like them I'll > >> see about giving you write access to the CVS repository. > > .... > >> > provides some facilities for testing the contents of the page. > >> > More could easily be added. Anyone interested? > >> > >> Ooh, yes please. That's pretty much exactly what I was thinking of. Yes please indeed! We're desperate for that kind of thing here too. > > Cool. :-) I'm in serious deadline hell for the next couple of weeks, > > but I'll try to find time to sneak this stuff out the door. > > Whenever. > > > I think send_diagnostics() isn't bad. Taking print out of the name is > > probably a good idea, I think it's misleading (at least it misled me). > > Maybe diagnostic_msg()? Or maybe $self->annotate(), in the sense that > > it's not part of the main output, and the runner controls how much > > annotation you want (e.g., never, only on fail, or always)? Just some > > additional brainstorming. > > Hmm... annotate definitely sounds possible. I like that too. annotate() it will be then. Might manage a commit later tonight ... |
|
From: Piers C. <pdc...@bo...> - 2001-12-13 23:12:31
|
Matthias Ferber <mf...@hi...> writes:
> On Thu, 13 Dec 2001, Piers Cawley wrote:
>> > optional module rather cuts into its usefulness. Am I blowing against the
>> > wind?
>>
>> I'm afraid you are. I'm strongly against reinventing wheels, and
>
> OK... I'm the Johnny-come-lately, and you make a good point, so I'll
> cheerfully agree, except for a little peep about making sure the
> dependency is well documented, which I'm sure is either done or planned,
> so I'll just go away now.
It's in Makefile.PL, which means that if you install it using the CPAN
module you'll have the chance to autoinstall CPAN. But I should
probably stick something in the README as well.
--
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?
|
|
From: Matthias F. <mf...@hi...> - 2001-12-13 17:15:51
|
On Thu, 13 Dec 2001, Piers Cawley wrote: > > optional module rather cuts into its usefulness. Am I blowing against the > > wind? > > I'm afraid you are. I'm strongly against reinventing wheels, and OK... I'm the Johnny-come-lately, and you make a good point, so I'll cheerfully agree, except for a little peep about making sure the dependency is well documented, which I'm sure is either done or planned, so I'll just go away now. |
|
From: Piers C. <pdc...@bo...> - 2001-12-13 08:24:04
|
Matthias Ferber <mf...@hi...> writes:
> Hi people,
>
> I've downloaded the most recent version of PerlUnit to get the
> renamed classes, and I'm hitting a problem involving the use of the
> Error class, which Test::Unit::Exception is derived from. (This is
> new since v1.14.)
Yup, that's Error from CPAN. You'll also need Class::Inner from CPAN
(which forgets to mention that it needs Test::More)
> Is this supposed to be Test::Unit::Error, or the Error.pm module from
> CPAN? It looks to me like it's probably the CPAN module, and if that's
> right, I don't think it's such a good thing. We don't have that module
> installed here, and while we're loose enough that I can get it installed
> without difficulty, I would think that having PerlUnit dependent on an
> optional module rather cuts into its usefulness. Am I blowing against the
> wind?
I'm afraid you are. I'm strongly against reinventing wheels, and
PerlUnit's hand rolled exception classes did just that. Error.pm gives
us a good implementation of exception objects and some really useful
syntax with which to use them.
> (And, of course, is there an alternative?)
Nope.
Same goes for Class::Inner, which was originally written (by me) with
this framework in mind as a replacement for the old, broken system. It
got released to CPAN as a seperate entity because it has the potential
to be useful outside PerlUnit (though I really should do another
release with better documentation...)
> By the way, I looked for discussion about this in the mailing list
> archives but I couldn't find anything. Sorry if I missed something that
> was there. If there's a way to search the archive I didn't see it. Grr.
There is a searchable archive somewhere. Can't remember where now of
course. (I'm so helpful aren't I). It probably got discussed in one of
the 'Refactoring' threads.
--
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?
|
|
From: Matthias F. <mf...@hi...> - 2001-12-13 01:04:14
|
> which Test::Unit::Exception is derived from. (This is new since v1.14.) I mean 0.14 of course... just looking forward to a release. :-) |
|
From: Matthias F. <mf...@hi...> - 2001-12-13 01:02:13
|
Hi people, I've downloaded the most recent version of PerlUnit to get the renamed classes, and I'm hitting a problem involving the use of the Error class, which Test::Unit::Exception is derived from. (This is new since v1.14.) Is this supposed to be Test::Unit::Error, or the Error.pm module from CPAN? It looks to me like it's probably the CPAN module, and if that's right, I don't think it's such a good thing. We don't have that module installed here, and while we're loose enough that I can get it installed without difficulty, I would think that having PerlUnit dependent on an optional module rather cuts into its usefulness. Am I blowing against the wind? (And, of course, is there an alternative?) By the way, I looked for discussion about this in the mailing list archives but I couldn't find anything. Sorry if I missed something that was there. If there's a way to search the archive I didn't see it. Grr. Matthias |
|
From: Piers C. <pdc...@bo...> - 2001-12-12 19:18:22
|
Matthias Ferber <mf...@hi...> writes:
> On Wed, 12 Dec 2001, Piers Cawley wrote:
>> Diffs would be good. If you start making more and we like them I'll
>> see about giving you write access to the CVS repository.
> ....
>> > provides some facilities for testing the contents of the page.
>> > More could easily be added. Anyone interested?
>>
>> Ooh, yes please. That's pretty much exactly what I was thinking of.
>
> Cool. :-) I'm in serious deadline hell for the next couple of weeks,
> but I'll try to find time to sneak this stuff out the door.
Whenever.
> I think send_diagnostics() isn't bad. Taking print out of the name is
> probably a good idea, I think it's misleading (at least it misled me).
> Maybe diagnostic_msg()? Or maybe $self->annotate(), in the sense that
> it's not part of the main output, and the runner controls how much
> annotation you want (e.g., never, only on fail, or always)? Just some
> additional brainstorming.
Hmm... annotate definitely sounds possible.
--
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?
|
|
From: Matthias F. <mf...@hi...> - 2001-12-12 18:37:47
|
On Wed, 12 Dec 2001, Piers Cawley wrote: > Diffs would be good. If you start making more and we like them I'll > see about giving you write access to the CVS repository. .... > > provides some facilities for testing the contents of the page. More > > could easily be added. Anyone interested? > > Ooh, yes please. That's pretty much exactly what I was thinking of. Cool. :-) I'm in serious deadline hell for the next couple of weeks, but I'll try to find time to sneak this stuff out the door. I think send_diagnostics() isn't bad. Taking print out of the name is probably a good idea, I think it's misleading (at least it misled me). Maybe diagnostic_msg()? Or maybe $self->annotate(), in the sense that it's not part of the main output, and the runner controls how much annotation you want (e.g., never, only on fail, or always)? Just some additional brainstorming. Matthias |
|
From: Piers C. <pdc...@bo...> - 2001-12-12 09:28:51
|
"Hans Donner" <co...@po...> writes:
> Hi there,
>
> Maybe an idea to package a new release before any new stuff is being
> added / refactored? (and with the current speed of changes to do
> this every month or so?) Im following the recent changes with great
> interest, but Im not such a CVS addict to retrieve the latest
> version being developed (currently I havent got the time; I work
> with PerlUnit only at home (my job does not include programming)).
Good idea. I'll see about packaging up what we have and shoving it on
sourceforge and CPAN.
--
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?
|
|
From: Piers C. <pdc...@bo...> - 2001-12-12 09:26:53
|
Matthias Ferber <mf...@hi...> writes:
> On Tue, 11 Dec 2001, Adam Spiers wrote:
>> > > It also occurred to me that a "nice-to-have" would be a verbose option
>> > > where it displays the name of each test and the TestCase class as it
>> > > progresses.
>> >
>> > Again, that's something to hang off the runner, and it definitely
>> > looks possible.
>>
>> Yep. Can you give us an example of the output you'd like to see? (Or
>> a patch ;-)
>
> Yeah, sure. I hadn't thought it through in detail but it shouldn't be
> hard to work up a simple patch. If I find time to do that, what should I
> do with it exactly? Send diffs?
Diffs would be good. If you start making more and we like them I'll
see about giving you write access to the CVS repository.
>> sub test_case {
>> my $self = shift;
>> ...
>> $self->print('some debugging\n');
>> ...
>> }
>>
>> and the debugging will only appear if the test case fails. This is
>> currently only supported by TestRunner.pm. Maybe we should think of
>> a better name than print().
>
> This sounds pretty cool. What's the thinking behind making $self->print()
> output only show up when tests fail? I'm guessing that the idea is that
> you can print details of what's going on in the test so that when the test
> fails you have to do less digging to find the problem, but it doesn't
> clutter up the screen when the test succeeds.
Yup. Remember that the print message gets sent to the
Listener/TestRunner. If you want a more verbose style you can easily
(must check that statement) subclass the TestRunner and change that
behaviour.
> If that's correct I think it's great. I wrote some tests in JUnit
> the other day where I could have really used this feature: I had to
> do a bunch of messing around with StringBuffers to cram a whole lot
> of data into the failure message.
>
> How about $self->print_on_fail()?
Nope. Deciding when/whether to print the message is a function of the
runner not of the testcase. C<$self->send_diagnostic(...)> anybody?
Hmm...
>> > And Test::Unit::Web would be nice, and something to do mock objects,
>> > and...
>
> Hmm... I'm not sure what Test::Unit::Web is meant to be, but... it
> so happens that my first trial use of PerlUnit has been to do some
> stock web site testing. We host a few hundred web sites, the
> majority of which are functionally identical but the rest of which
> differ to varying degrees, so I took pains to make the code general
> and reusable. If that's what Test::Unit::Web would be about, my base
> class could possibly make a decent starting point. It tests that a
> page loads successfully within a customizable number of seconds, and
> provides some facilities for testing the contents of the page. More
> could easily be added. Anyone interested?
Ooh, yes please. That's pretty much exactly what I was thinking of.
--
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?
|
|
From: Hans D. <co...@po...> - 2001-12-12 05:57:30
|
Hi there, Maybe an idea to package a new release before any new stuff is being added= / refactored? (and with the current speed of changes to do this every= month or so?) Im following the recent changes with great interest, but Im not such a CVS= addict to retrieve the latest version being developed (currently I havent= got the time; I work with PerlUnit only at home (my job does not include= programming)). _ Greetings, Hans Donner |
|
From: Matthias F. <mf...@hi...> - 2001-12-11 18:37:56
|
On Tue, 11 Dec 2001, Adam Spiers wrote:
> > > It also occurred to me that a "nice-to-have" would be a verbose option
> > > where it displays the name of each test and the TestCase class as it
> > > progresses.
> >
> > Again, that's something to hang off the runner, and it definitely
> > looks possible.
>
> Yep. Can you give us an example of the output you'd like to see? (Or
> a patch ;-)
Yeah, sure. I hadn't thought it through in detail but it shouldn't be
hard to work up a simple patch. If I find time to do that, what should I
do with it exactly? Send diffs?
> sub test_case {
> my $self = shift;
> ...
> $self->print('some debugging\n');
> ...
> }
>
> and the debugging will only appear if the test case fails. This is
> currently only supported by TestRunner.pm. Maybe we should think of
> a better name than print().
This sounds pretty cool. What's the thinking behind making $self->print()
output only show up when tests fail? I'm guessing that the idea is that
you can print details of what's going on in the test so that when the test
fails you have to do less digging to find the problem, but it doesn't
clutter up the screen when the test succeeds. If that's correct I think
it's great. I wrote some tests in JUnit the other day where I could have
really used this feature: I had to do a bunch of messing around with
StringBuffers to cram a whole lot of data into the failure message.
How about $self->print_on_fail()?
> > And Test::Unit::Web would be nice, and something to do mock objects,
> > and...
Hmm... I'm not sure what Test::Unit::Web is meant to be, but... it so
happens that my first trial use of PerlUnit has been to do some stock web
site testing. We host a few hundred web sites, the majority of which are
functionally identical but the rest of which differ to varying degrees, so
I took pains to make the code general and reusable. If that's what
Test::Unit::Web would be about, my base class could possibly make a decent
starting point. It tests that a page loads successfully within a
customizable number of seconds, and provides some facilities for testing
the contents of the page. More could easily be added. Anyone interested?
Matthias
|
|
From: Adam S. <ad...@sp...> - 2001-12-11 18:12:44
|
Adam Spiers (ad...@sp...) wrote:
> Piers Cawley (pdc...@bo...) wrote:
> > Matthias Ferber <mf...@hi...> writes:
> > How about:
> >
> > $self->assert_matches(qr/.../, $value, $message)
> > $self->assert_does_not_match(qr/.../, $value, $message)
> >
> > assert_matches is almost exactly like assert(qr/.../), but it fails if
> > it's not passed a pattern as its first argument.
>
> Sounds good. I might hack that up now ...
Done. I actually ended up making substantial improvements to
AssertTest.pm, so the tests therein are even more stringent than
before. As a result it's even more likely that if I cocked something
up, it's broken 'make test'. Works for me of course, but please cvs
update and test. Here's the log message for those not on
perlunit-commits yet:
- Add new assert_matches() and assert_does_not_match() assertions,
as requested by Matthias Ferber, and new tests for them of course.
- Start testing for the correct messages in T::U::Failure objects
(see check_exception()). In particular this tests that the optional
MESSAGE args are processed correctly when reporting failures.
- Improved behaviour of assert_equals() and assert_not_equals() with
undefined parameters.
- Added more stringent tests for assert_equals() and assert_not_equals().
Some of these are possibly debatable. I think the assert_equals()
matrix should be retired in favour of the check_failures() style tests
used to check assert_not_equals(), since the latter also check the
failure message and originating file/line (added a #FIXME for this).
- Fixed reversed got/expected message with $self->ok(sub { 2 + 2 }, 4);
Spotted this as a bonus of the new check_exception(), yay.
I'm off to Jersey tomorrow morning until Sunday, so I won't be
available until I get back.
|
|
From: Adam S. <ad...@sp...> - 2001-12-11 15:28:07
|
Piers Cawley (pdc...@bo...) wrote:
> Matthias Ferber <mf...@hi...> writes:
> > 1) There's no indication yet (that I noticed) of which methods in an
> > object are intended to be the public interface and which are for internal
> > use only.
Yeah, this is bad. Eventually all public methods should be documented
by accompanying pod, I guess.
> I'd consider do_run to be a 'semi' private method. You're going to
> need to know about it if you're writing a Runner, but most of the time
> you're not going to go near it.
Agreed. The fact that PerlUnit is aimed at developers is inevitably
going to blur the lines between private/public.
> > 2) I was going to ask if there were any plans for specialized assert()
> > methods, like assert_equals, but I see that this is already the direction
> > you're moving in, which is great. In particular, I'd like to put in a
> > plug for assert_matches(regex, string) and assert_not_matches (or
> > something). The scheme for using assert() with a regex as the first
> > parameter is cool, but to test a non-match you have to use a hack, and in
> > either case you're limited to the default failure message, which for a
> > regex is likely to be unhelpful.
> >
> > ---Whooops, I see that the message parameter has been added more recently.
> > That's terrific. It would still be nice to have a not-matches assertion,
> > though, to avoid the (?!) hack. I'm doing this kind of test, and I
> > resorted to the scalar(x=~y) syntax instead because it seemed less ugly.
> > (I've just discovered the neat trick in Assert.pm for reusing coderefs as
> > assertions. That's cool.)
>
> Thanks. I did the Assert reworking and looking at it now I seem to
> have overcomplicated it somewhat, but it's definitely flexible :).
>
> How about:
>
> $self->assert_matches(qr/.../, $value, $message)
> $self->assert_does_not_match(qr/.../, $value, $message)
>
> assert_matches is almost exactly like assert(qr/.../), but it fails if
> it's not passed a pattern as its first argument.
Sounds good. I might hack that up now ...
> > 3) Without turning Perl autoflushing on, you can't see the tests
> > proceeding in a text-based test. It would be cool if the suite, or
> > whichever class does the output, could ensure that $| is nonzero so the
> > dots get displayed as soon as their written. (Maybe it could even restore
> > the original value.) I'm doing that explicitly in the script I've
> > written.
>
> That's something for the Runner class. I would be nice though.
Committed ...
> > It also occurred to me that a "nice-to-have" would be a verbose option
> > where it displays the name of each test and the TestCase class as it
> > progresses.
>
> Again, that's something to hang off the runner, and it definitely
> looks possible.
Yep. Can you give us an example of the output you'd like to see? (Or
a patch ;-)
> > I don't think JUnit has that either, but I found myself
> > wanting it yesterday. (Ooh, I see you've made the debug setting global.
> > Very nice.)
>
> I'm seriously considering hiding the debug variable from end users and
> providing a bunch of ->debug, ->info, ->notice type methods which the
> runner can display or not as it chooses and using the debug variable
> solely for framework debugging stuff. One of the problems with the old
> stack dump stuff for instance was that it was only really of any use
> to framework developers, and it was a pig to turn off.
I better summarise the status quo w.r.t. debugging just in case my
recent changes have confused anyone. First, there is no longer a
DEBUG constant anywhere; it has been replaced with a more unified
approach in Test::Unit::Debug. This means debugging no longer gets
optimised out by the compile phase, but it's extremely unlikely that
this will cause anything more than a negligible performance hit.
Test::Unit::Debug is another case of "semi-privacy"; you can use it if
you want, but it's only really there for people messing around with
the framework. On the other hand, if you want to debug your own test
cases, you can now do
sub test_case {
my $self = shift;
...
$self->print('some debugging\n');
...
}
and the debugging will only appear if the test case fails. This is
currently only supported by TestRunner.pm. Maybe we should think of
a better name than print().
> And then the fun really begins. I want something which will make it
> easty for non programmers to specify acceptance tests for instance.
> And Test::Unit::Web would be nice, and something to do mock objects,
> and...
Worth chucking these ideas in doc/TODO, even if they are a bit vague
at the moment?
|
|
From: Piers C. <pdc...@bo...> - 2001-12-10 23:02:29
|
Matthias Ferber <mf...@hi...> writes:
> Hi folks -- you've all probably seen Christian's and Piers's responses to
> my query on the other newsgroup, so I won't repeat all the background
> here. (I thought I remembered seeing something on sourceforge about this
> list being the totally dead one and the other one only mostly dead, but
> apparently my memory was playing tricks on me.) Christian and Piers,
> thanks to both of you for the fast and helpful answers. It looks like the
> interface changes in progress are mostly things a little searching and
> replacing could take care of, so I'm going to press onward with what I'm
> doing.
>
> At any rate, I'm really liking PerlUnit in its current form and I'd like
> to be of assistance however I can. For the moment that's probably limited
> to enthusiastic feedback and questions, but perhaps in the future I'll
> have time to be more constructive if you're looking for more help.
>
> I do have these bits of feedback and suggestions, nothing major. Bear in
> mind that I don't know what you're working on now, although I've been
> browsing the CVS tree and I see that you've anticipated at least some of
> these things...
>
> 1) There's no indication yet (that I noticed) of which methods in an
> object are intended to be the public interface and which are for internal
> use only. This is important for what I'm working on, because (for reasons
> that I won't go into here) I need to invoke TestSuite::do_run() directly
> from a script instead of invoking a TestRunner. If that method isn't
> meant to be public, then I'll need to find a workaround, which may lead to
> a feature request. [Actually I think I've just figured out how I can
> avoid using this method directly, but still...]
I'd consider do_run to be a 'semi' private method. You're going to
need to know about it if you're writing a Runner, but most of the time
you're not going to go near it.
>
> 2) I was going to ask if there were any plans for specialized assert()
> methods, like assert_equals, but I see that this is already the direction
> you're moving in, which is great. In particular, I'd like to put in a
> plug for assert_matches(regex, string) and assert_not_matches (or
> something). The scheme for using assert() with a regex as the first
> parameter is cool, but to test a non-match you have to use a hack, and in
> either case you're limited to the default failure message, which for a
> regex is likely to be unhelpful.
>
> ---Whooops, I see that the message parameter has been added more recently.
> That's terrific. It would still be nice to have a not-matches assertion,
> though, to avoid the (?!) hack. I'm doing this kind of test, and I
> resorted to the scalar(x=~y) syntax instead because it seemed less ugly.
> (I've just discovered the neat trick in Assert.pm for reusing coderefs as
> assertions. That's cool.)
Thanks. I did the Assert reworking and looking at it now I seem to
have overcomplicated it somewhat, but it's definitely flexible :).
How about:
$self->assert_matches(qr/.../, $value, $message)
$self->assert_does_not_match(qr/.../, $value, $message)
assert_matches is almost exactly like assert(qr/.../), but it fails if
it's not passed a pattern as its first argument.
> 3) Without turning Perl autoflushing on, you can't see the tests
> proceeding in a text-based test. It would be cool if the suite, or
> whichever class does the output, could ensure that $| is nonzero so the
> dots get displayed as soon as their written. (Maybe it could even restore
> the original value.) I'm doing that explicitly in the script I've
> written.
That's something for the Runner class. I would be nice though.
> It also occurred to me that a "nice-to-have" would be a verbose option
> where it displays the name of each test and the TestCase class as it
> progresses.
Again, that's something to hang off the runner, and it definitely
looks possible.
> I don't think JUnit has that either, but I found myself
> wanting it yesterday. (Ooh, I see you've made the debug setting global.
> Very nice.)
I'm seriously considering hiding the debug variable from end users and
providing a bunch of ->debug, ->info, ->notice type methods which the
runner can display or not as it chooses and using the debug variable
solely for framework debugging stuff. One of the problems with the old
stack dump stuff for instance was that it was only really of any use
to framework developers, and it was a pig to turn off.
> The SourceForge feature request tracker doesn't seem to be getting
> much use but I could put these in there if that would help. Again,
> you guys are doing really good work here. I was very surprised,
> incidentally, that a Perl port wasn't finished long ago, but go
> figure.
It's sort of confusing. It's sort of finished, but it is also poorly
documented and much harder to extend than it should be. It's been
usable for a long time now, but it's been, well, ragged 'round the
edges so we need to get those tidied up before we can slap a 1.0 label
on it.
And then the fun really begins. I want something which will make it
easty for non programmers to specify acceptance tests for instance.
And Test::Unit::Web would be nice, and something to do mock objects,
and...
--
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?
|
|
From: Matthias F. <mf...@hi...> - 2001-12-10 18:43:52
|
Hi folks -- you've all probably seen Christian's and Piers's responses to my query on the other newsgroup, so I won't repeat all the background here. (I thought I remembered seeing something on sourceforge about this list being the totally dead one and the other one only mostly dead, but apparently my memory was playing tricks on me.) Christian and Piers, thanks to both of you for the fast and helpful answers. It looks like the interface changes in progress are mostly things a little searching and replacing could take care of, so I'm going to press onward with what I'm doing. At any rate, I'm really liking PerlUnit in its current form and I'd like to be of assistance however I can. For the moment that's probably limited to enthusiastic feedback and questions, but perhaps in the future I'll have time to be more constructive if you're looking for more help. I do have these bits of feedback and suggestions, nothing major. Bear in mind that I don't know what you're working on now, although I've been browsing the CVS tree and I see that you've anticipated at least some of these things... 1) There's no indication yet (that I noticed) of which methods in an object are intended to be the public interface and which are for internal use only. This is important for what I'm working on, because (for reasons that I won't go into here) I need to invoke TestSuite::do_run() directly from a script instead of invoking a TestRunner. If that method isn't meant to be public, then I'll need to find a workaround, which may lead to a feature request. [Actually I think I've just figured out how I can avoid using this method directly, but still...] 2) I was going to ask if there were any plans for specialized assert() methods, like assert_equals, but I see that this is already the direction you're moving in, which is great. In particular, I'd like to put in a plug for assert_matches(regex, string) and assert_not_matches (or something). The scheme for using assert() with a regex as the first parameter is cool, but to test a non-match you have to use a hack, and in either case you're limited to the default failure message, which for a regex is likely to be unhelpful. ---Whooops, I see that the message parameter has been added more recently. That's terrific. It would still be nice to have a not-matches assertion, though, to avoid the (?!) hack. I'm doing this kind of test, and I resorted to the scalar(x=~y) syntax instead because it seemed less ugly. (I've just discovered the neat trick in Assert.pm for reusing coderefs as assertions. That's cool.) 3) Without turning Perl autoflushing on, you can't see the tests proceeding in a text-based test. It would be cool if the suite, or whichever class does the output, could ensure that $| is nonzero so the dots get displayed as soon as their written. (Maybe it could even restore the original value.) I'm doing that explicitly in the script I've written. It also occurred to me that a "nice-to-have" would be a verbose option where it displays the name of each test and the TestCase class as it progresses. I don't think JUnit has that either, but I found myself wanting it yesterday. (Ooh, I see you've made the debug setting global. Very nice.) The SourceForge feature request tracker doesn't seem to be getting much use but I could put these in there if that would help. Again, you guys are doing really good work here. I was very surprised, incidentally, that a Perl port wasn't finished long ago, but go figure. Gotta get back to my real job now. -- Matthias Ferber mf...@hi... |
|
From: Piers C. <pdc...@bo...> - 2001-12-10 09:01:44
|
Christian Lemburg <le...@ai...> writes:
> Matthias Ferber <mf...@hi...> writes:
>
>> Hi folks,
>>
>> This seems to be a near-dead mailing list, but perhaps still the best way
>> to contact the minds behind PerlUnit. So, tally-ho. (There does seem to
>> be activity on SourceForge, so I'm hopeful that I'm not yelling into a
>> vacuum here.)
>
> No you are not - but the main activity is happening on perlunit-devel.
>
>> I'm leading a rather optimistic covert effort to popularize JUnit and
>> friends in my company's development environment. We use both Java and
>> Perl, which makes PerlUnit an attractive variant. I've been playing with
>> it over the last few days and I like it, but the available docs don't
>> supply a lot of context for gauging where it is.
>>
>> My main question is, can you give me any vague idea of how stable you feel
>> PerlUnit is at this point? I'd like very much to put it to active use at
>> work to some extent. It's clearly still well in the development stage, so
>> I understand that anything I do with it is At My Own Risk. But I'm hoping
>> that if this is a really bad idea at this point because everything is
>> going to change completely, someone will wave me off, at least.
>
> Well, let's put it that way: nearly all of the email that I have
> received and a lot of the posts on perlunit-devel seem to indicate
> that people do already use PerlUnit at work.
>
> I don't think that everything is going to change completely, but you
> might have a word about that with the folks on perlunit-devel. Still,
> the basic idea is to provide an implementation of the XUnit framework
> for Perl, and that is relatively stable. Do you have any specific
> things you are worried about?
Actually, we're in the process of changing the interface quite a bit:
All those Test::Unit::TestFoo type classes are tending to become
Test::Unit::Foo type classes for instance. We're also trying to work
out how to rename Test::Unit::TestHarness and Test::Unit::HarnessTest
to something a little less confusing. Test::Unit is now
Test::Unit::Procedural and Test::Unit is just a place holder for docs
pointing the reader at the 'real' classes. There's a whole bunch of
stuff in /docs/TODO on the HEAD CVS branch which points at what will
be changing for a 1.0 release (which is looking unlikely before
Christmas unless I get my finger out)
Hopefully the changes are actually going to lead to an easier to use,
easier to understand PerlUnit (for instance, the latest version in CVS
has a working 'assert_equals' that does the right thing in most cases.
Which is nice...)
>> My second question is whether you're interested in feedback from
>> whatever there is of a user community, i.e. (as far as I know) me.
>> I have a couple of minor suggestions based on a couple of days of
>> use that I'd be happy to toss up if anyone is interested.
>
> Oh yes, very interested. Please join the perlunit-devel mailing list
> or just keep posting to this list (perlunit-users), and mail us your
> comments and criticisms. Feedback is always welcome.
Absolutely. The new docs even have a 'FEEDBACK' section essentially
asking anyone who uses the framework to let us know and tell us of any
niggles they have (or even things that they really like so we know
what to leave alone.)
--
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?
|
|
From: Christian L. <le...@ai...> - 2001-12-10 07:22:04
|
Matthias Ferber <mf...@hi...> writes: > Hi folks, > > This seems to be a near-dead mailing list, but perhaps still the best way > to contact the minds behind PerlUnit. So, tally-ho. (There does seem to > be activity on SourceForge, so I'm hopeful that I'm not yelling into a > vacuum here.) No you are not - but the main activity is happening on perlunit-devel. > I'm leading a rather optimistic covert effort to popularize JUnit and > friends in my company's development environment. We use both Java and > Perl, which makes PerlUnit an attractive variant. I've been playing with > it over the last few days and I like it, but the available docs don't > supply a lot of context for gauging where it is. > > My main question is, can you give me any vague idea of how stable you feel > PerlUnit is at this point? I'd like very much to put it to active use at > work to some extent. It's clearly still well in the development stage, so > I understand that anything I do with it is At My Own Risk. But I'm hoping > that if this is a really bad idea at this point because everything is > going to change completely, someone will wave me off, at least. Well, let's put it that way: nearly all of the email that I have received and a lot of the posts on perlunit-devel seem to indicate that people do already use PerlUnit at work. I don't think that everything is going to change completely, but you might have a word about that with the folks on perlunit-devel. Still, the basic idea is to provide an implementation of the XUnit framework for Perl, and that is relatively stable. Do you have any specific things you are worried about? > My second question is whether you're interested in feedback from whatever > there is of a user community, i.e. (as far as I know) me. I have a couple > of minor suggestions based on a couple of days of use that I'd be happy to > toss up if anyone is interested. Oh yes, very interested. Please join the perlunit-devel mailing list or just keep posting to this list (perlunit-users), and mail us your comments and criticisms. Feedback is always welcome. Cheers, Christian Lemburg P.S.: Please note that I do not maintain Test::Unit anymore. The new maintainer is Piers Cawley together with the folks on the PerlUnit sourceforge group. > Regards -- and thanks for doing the work so far on this. > > -- Matthias Ferber > mf...@hi... > > > > _______________________________________________ > Perlunit-users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perlunit-users > -- Christian Lemburg, <le...@ai...>, http://www.clemburg.com/ An American's a person who isn't afraid to criticize the President but is always polite to traffic cops. |
|
From: Adam M. <am...@co...> - 2001-12-04 19:46:59
|
Adam Spiers <as...@gu...> spake: > You could avoid the fork() to and dependency on an external program: > > use FindBin qw($Script); > die "Usage: $Script <modules>\n" unless @ARGV; > Cool! Looks like File::Basename also exists, but I haven't tried that one. > > I would like to contribute to this package if you want/need > any help. > > Yes please! Like Christian said, the biggest help to us right now is > feedback on how the CVS tree works for you. I'll start using that right away. Thank you, Adam |
|
From: Adam S. <as...@gu...> - 2001-12-04 14:57:59
|
Adam Monsen <am...@co...> writes:
> I'm liking Test::Unit. I've never used JUnit, but now I'll never have to!
> (or at least I'll learn JUnit faster whenever I do start coding in Java)
>
> I've been using Test::Unit::TestCase with excellent results.
Great :-)
> Test::Unit::TestRunner is quite handy. I use the following script to run
> tests...
>
> #!/usr/bin/perl -w
> use Test::Unit::TestRunner;
> use strict;
>
> chomp(my $script = `basename $0`);
> die "Usage: $script <modules>\n" unless @ARGV;
> for (@ARGV) {
> s/\.pm//g;
> my $testrunner = Test::Unit::TestRunner->new();
> $testrunner->start($_);
> print "\n"; # make it pretty
> }
>
> I use basename becuase I think it should recognize filenames as well as
> modules.
You could avoid the fork() to and dependency on an external program:
use FindBin qw($Script);
die "Usage: $Script <modules>\n" unless @ARGV;
> The added newline is because TestRunner doesn't print one after
> printing out timing information.
Please try checking out the CVS tree and using that. There have been
many improvements made to it since the last tarball release, including
ones fixing newline issues such as this.
> Here are a few issues/requests/whatever I have with Test::Unit...
> 1. Is there any way to order tests?
Yes, in the CVS version. See the NOTES section of the
Test::Unit::TestCase man page. Piers: any objection to making
list_tests sort lexically? I think it's a very convenient default,
and it won't cost anything significant in terms of performance. BTW,
personally I wouldn't call having to use package lexicals/globals for
persistent data a bug. Seems a pretty nice, logical way of doing it
to me.
> 2. Is there any way to plan for X number of tests like with Test.pm?
This is already taken care of by the Test::Unit::HarnessUnit runner,
which outputs in the same format that Test::Harness expects. However,
the "native" PerlUnit runner Test::Unit::TestRunner doesn't bother
with planning tests.
> 3. Listing the test names would be cool, this could be a "verbose" option or
> something. I usually do something like this:
> sub test_email_results {
> my $self = shift;
> warn +(caller 0)[3]."\n";
> # Test Code Here
> }
As of yesterday, CVS contains a unified debugging mechanism, so you
can turn on debugging in the packages of your choosing from your
runner. See TestRunner.pl for an example of this.
> 4. when an assert fails, it would be nice to know on what line the failure
> occurred
This is supposed to happen in CVS now, although I think it's broken
for the assertion methods created in Assert.pm via %assert_subs.
Something to do with messing around with $Error::Depth, but I don't
fully understand how this is supposed to work yet. Piers, any ideas?
We need a test for this too. The problem is listed in doc/TODO.
> 5. I can't get quell_backtrace() to work (ie: a test sub dies, and a
> backtrace is given even if $self->quell_backtrace() is called within the
> same test sub). Where should I put a call to this method to get it to
> actually work?
In CVS, quell_backtrace() is no more; it has ceased to be, kicked the
bucket, snuffed it. It is an ex-method ...
> I would like to contribute to this package if you want/need any help.
Yes please! Like Christian said, the biggest help to us right now is
feedback on how the CVS tree works for you.
> It's
> interesting, and I'm excited to make good use of it. I have a heightened
> sense of awareness about software testing after reading about the Therac-25
> accidents <http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html>,
> but I have much to learn about effective testing.
Let's hope our bugs don't have consequences as bad as that 8-)
Adam
|
|
From: Christian L. <le...@ai...> - 2001-12-04 09:55:31
|
Hi Adam, Thanks for your patch and contributions! Please note that I do not maintain Test::Unit anymore. The new maintainer is Piers Cawley and the other folks on the perlunit.sourceforge.net group - see http://perlunit.sourceforge.net/ . I have copied your mail on to the development mailing list of PerlUnit, as the group effort at sourceforge is called. Please join these mailing lists: per...@li... per...@li... The devel group is much more alive, you should post there. Please join the group effort, if you feel you want to contribute to PerlUnit. The project is in need of people with experience in testing with this software, especially for documentation and contributions of examples of real-life testing scripts. Cheers, Christian Lemburg Adam Monsen <am...@co...> writes: > I'm liking Test::Unit. I've never used JUnit, but now I'll never have to! > (or at least I'll learn JUnit faster whenever I do start coding in Java) > > I've been using Test::Unit::TestCase with excellent results. > Test::Unit::TestRunner is quite handy. I use the following script to run > tests... > > #!/usr/bin/perl -w > use Test::Unit::TestRunner; > use strict; > > chomp(my $script = `basename $0`); > die "Usage: $script <modules>\n" unless @ARGV; > for (@ARGV) { > s/\.pm//g; > my $testrunner = Test::Unit::TestRunner->new(); > $testrunner->start($_); > print "\n"; # make it pretty > } > > I use basename becuase I think it should recognize filenames as well as > modules. The added newline is because TestRunner doesn't print one after > printing out timing information. Here's a patch to fix that... > > *** TestRunner.pm.old Mon Dec 3 13:48:45 2001 > --- TestRunner.pm Mon Dec 3 13:49:19 2001 > *************** > *** 60,66 **** > my $run_time = timediff($end_time, $start_time); > $self->_print("\n", "Time: ", timestr($run_time), "\n"); > > ! $self->print_result($result); > > if ($wait) { > print "<RETURN> to continue"; # go to STDIN any case > --- 60,66 ---- > my $run_time = timediff($end_time, $start_time); > $self->_print("\n", "Time: ", timestr($run_time), "\n"); > > ! $self->print_result($result), print "\n"; > > if ($wait) { > print "<RETURN> to continue"; # go to STDIN any case > > > Here are a few issues/requests/whatever I have with Test::Unit... > 1. Is there any way to order tests? > 2. Is there any way to plan for X number of tests like with Test.pm? > 3. Listing the test names would be cool, this could be a "verbose" option or > something. I usually do something like this: > sub test_email_results { > my $self = shift; > warn +(caller 0)[3]."\n"; > # Test Code Here > } > 4. when an assert fails, it would be nice to know on what line the failure > occurred (could also apply to the "verbose" setting). I do use the second > argument to assert() to add descriptive text, and I guess I could always add > __LINE__ or (caller(0))[2] or something. > 5. I can't get quell_backtrace() to work (ie: a test sub dies, and a > backtrace is given even if $self->quell_backtrace() is called within the > same test sub). Where should I put a call to this method to get it to > actually work? > > I would like to contribute to this package if you want/need any help. It's > interesting, and I'm excited to make good use of it. I have a heightened > sense of awareness about software testing after reading about the Therac-25 > accidents <http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html>, > but I have much to learn about effective testing. > > > Adam Monsen > -- Christian Lemburg le...@ai... |
|
From: Piers C. <pdc...@bo...> - 2001-12-01 17:16:50
|
Adam Spiers <ad...@sp...> writes:
> Piers Cawley (pdc...@bo...) wrote:
>> I've created a perlunit-commits mailing list and set up a loginfo
>> entry to get any commit notifications mailed to the list.
>>
>> Need to do some voodoo to make sure it only gets commits mailed to it,
>> and it's currently not visible from the project page, but if you could
>> subscribe my mailing per...@li... that would
>> be a good thing.
>
> Cool, I was just thinking how that would be a good thing to have.
> Which script have you used? I took that godawful loginfo.pl written
> by Sascha Schumann and rewrote virtually the whole thing for use here
> at work; it's quite nice now, and does handy stuff like forking itself
> off correctly so your cvs commit finishes immediately rather than
> waiting for the script to terminate. It also integrates with
> bonsai/cvsweb/bugzilla, although that won't help PerlUnit.
Hmm... I've just piped it to Mail for now. If you want to fix it feel
free to check out CVSROOT and fix it up for something a little neater.
--
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?
|
|
From: Adam S. <ad...@sp...> - 2001-11-30 16:49:31
|
Piers Cawley (pdc...@bo...) wrote: > I've created a perlunit-commits mailing list and set up a loginfo > entry to get any commit notifications mailed to the list. > > Need to do some voodoo to make sure it only gets commits mailed to it, > and it's currently not visible from the project page, but if you could > subscribe my mailing per...@li... that would > be a good thing. Cool, I was just thinking how that would be a good thing to have. Which script have you used? I took that godawful loginfo.pl written by Sascha Schumann and rewrote virtually the whole thing for use here at work; it's quite nice now, and does handy stuff like forking itself off correctly so your cvs commit finishes immediately rather than waiting for the script to terminate. It also integrates with bonsai/cvsweb/bugzilla, although that won't help PerlUnit. |
2 messages has been excluded from this view by a project administrator.
