perlunit-users — PerlUnit users' mailing list

Re: [Perlunit-users] Using @TESTS for changing tests execution order

[Dmitry D. <dd...@ic...>]

Phlip wrote:

>>Suppose that one test is for database INSERT statement, and the other --
>>for SELECT, and that last -- for DELETE. That way I need to maintain the
>>order of tests execution. Of course, I can put all operations into one
>>test instead.
> 
> 
> Uh, one common trick here is to put into setUp() a BEGIN TRANSACTION, then
> put into tearDown a ROLLBACK.
> 
> But it sounds like you should randomize the order of your tests. Unless you
> are testing quite crufty legacy code, where you must rely on a certain
> amount of setUp before testing everything, your tests should all be totally
> severable.
> 
> When you achieve that, come back to me and tell me how you did it. ;-)
> 
> --
> Phlip
> http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
> 

Can you suggest a structure of tests for testing insert, select and 
delete operations? I suppose that I can write something like tis:

sub test_001_insert {
... insert record and do some tets
}

sub test_002_select {
... select record inserted in previous test and do some tets
}

sub test_003_delete {
... delete the above  record and do some tets
}

-- 
Dmitry.

Re: [Perlunit-users] Nobody here?

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

Dmitry Diskin (dd...@ic...) wrote:
> Hi poeople!
> 
> It's very strange to see noone answering my questions here...  Where are 
> you?

I'm still reading but have next to no time to help out, sorry :-(

As I believe I already mentioned a while ago, I'll try to make a
release sometime with all the latest bugfixes which have been
submitted, and then hand over maintainership to someone suitably
equipped with the necessary skills and free time ...

Re: [Perlunit-users] How to exit from test suite?

[Dmitry D. <dd...@ic...>]

Matthew Astley wrote:

> On Sat, Oct 04, 2003 at 01:16:08PM +0400, Dmitry Diskin wrote:
> 
> 
>>If one of my tests fail,
> 
> 
> One particular test, or any of them?  Tests are often considered to be
> independent, at least to a large extent.
> 
> 
>>other tests should not be executed. In order to stop execution, I
>>use the following code:
>>
>>sub test_001_load {
> 
> 
> On the choice of method name, is the numbering just for convenience or
> were you relying on one test's side-effects to do something for the
> next one?  The manpage for Test::Unit::TestCase (notes section) talks
> about this a bit.
> 
> 
>>    my $self = shift;
>>    if ($loaded_nok) {
>>        $self->fail("Unrecoverable error, can't continue.");
>>        exit;
>>    }
>>}
> 
> 
> I haven't done anything like this with perlunit, but in JUnit running
> from an Ant file, I have put aside a set of tests to run first.  They
> check things like the presence of the database we're just about to run
> the hundred tests against - 100 failures aren't very useful.
> 
> You could do this by generating test suites by some means and having a
> more customised testrunner script.
> 
> 
>>Is it a proper way? Is there any $suite->stop method?
> 
> 
> Hmm, there's a Test::Unit::Result->stop() which would appear to do
> what you want.  I'm not sure what the proper answer is, and I don't
> claim to have read the docs recently.  8-}
> 
> You'd need to get the 'result' object from the 'suite' which creates
> it.  $testrunner->result()->stop() would work, but this is probably a
> "dirty" solution.
> 
> A neater way might be to register a Test::Unit::Listener (I haven't
> tried) and use the add_failure event to fish the Result object out
> from the failure exception?
> 
> 
> Remember, there's more than one way to do it!
> 
> Matthew  #8-)

I was unable to find a way to call $testrunner->result()->stop() from my 
  testcase. How can I access testrunner instance from testCase?

-- 
Dmitry.

Re: [Perlunit-users] Using @TESTS for changing tests execution order

[Phlip <pl...@sy...>]

> Suppose that one test is for database INSERT statement, and the other --
> for SELECT, and that last -- for DELETE. That way I need to maintain the
> order of tests execution. Of course, I can put all operations into one
> test instead.

Uh, one common trick here is to put into setUp() a BEGIN TRANSACTION, then
put into tearDown a ROLLBACK.

But it sounds like you should randomize the order of your tests. Unless you
are testing quite crufty legacy code, where you must rely on a certain
amount of setUp before testing everything, your tests should all be totally
severable.

When you achieve that, come back to me and tell me how you did it. ;-)

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

Re: [Perlunit-users] Using @TESTS for changing tests execution order

[Dmitry D. <dd...@ic...>]

Matthew Astley wrote:
> On Sat, Oct 04, 2003 at 10:06:19AM +0400, Dmitry Diskin wrote:
> 
> 
>>I read from TestCase.pm POD that one can populate @TESTS array in
>>order to specify the desired order of tests execution:
> 
> 
> Ah, I started at the bottom of my inbox and worked back...  why does
> it matter what order the tests run?  The xUnit idea is that each test
> (and its associated setup/teardown) should stand alone.

Suppose that one test is for database INSERT statement, and the other -- 
for SELECT, and that last -- for DELETE. That way I need to maintain the 
order of tests execution. Of course, I can put all operations into one 
test instead.


> 
> 
>>### quote begin
>>
>>If you need to specify the test order, you can do one of the
>>following:
>>
>>=over 4
>>
>>=item * Set @TESTS
>>
>>  our @TESTS = qw(my_test my_test_2);
>>
>>This is the simplest, and recommended way.
>>
>>### quote end
> 
> 
>>But the above does not work for me. I can include only desired tests
>>using @TESTS, but they are listed and executed in a random order,
> 
> 
> Hmm, that comment seems to be out of date.  @TESTS is piled into a
> hash, then the keys are listed as you said.
> 

Aha.. That is the clue! Thanks. I should study sources myself :)

>>I decided to override list_tests method like this:
>>
>>sub list_tests {
>>    my $self = shift;
>>    return sort $self->SUPER::list_tests(@_);
>>}
> 
> 
> That would do it, yes.  Did you see in Test/Unit/TestCase.pm,
> 
>   # Returns a list of the tests run by this class and its superclasses.
>   # DO NOT OVERRIDE THIS UNLESS YOU KNOW WHAT YOU ARE DOING!
>   sub list_tests {
>       ...
> 
> Maybe that comment could be more helpful...  8-/
> 
> 
>>It works as expected. What do you think? Am I missing something?
> 
> 
> Well it could be that you are missing something.  If you try to avoid
> using side effects from each test, then the order should not matter.
> 
> I suppose one day the tests may be run in parallel.  That would be
> neat, and it would also be incompatible with explicit test ordering.
> 

Hmm.. Never thought about parallel execution.. Indeed it may be a godd idea.

-- 
Dmitry.

Re: [Perlunit-users] Using @TESTS for changing tests execution order

[Matthew A. <mc...@us...>]

On Sat, Oct 04, 2003 at 10:06:19AM +0400, Dmitry Diskin wrote:

> I read from TestCase.pm POD that one can populate @TESTS array in
> order to specify the desired order of tests execution:

Ah, I started at the bottom of my inbox and worked back...  why does
it matter what order the tests run?  The xUnit idea is that each test
(and its associated setup/teardown) should stand alone.


> ### quote begin
> 
> If you need to specify the test order, you can do one of the
> following:
> 
> =over 4
> 
> =item * Set @TESTS
> 
>   our @TESTS = qw(my_test my_test_2);
> 
> This is the simplest, and recommended way.
> 
> ### quote end

> But the above does not work for me. I can include only desired tests
> using @TESTS, but they are listed and executed in a random order,

Hmm, that comment seems to be out of date.  @TESTS is piled into a
hash, then the keys are listed as you said.

> I decided to override list_tests method like this:
> 
> sub list_tests {
>     my $self = shift;
>     return sort $self->SUPER::list_tests(@_);
> }

That would do it, yes.  Did you see in Test/Unit/TestCase.pm,

  # Returns a list of the tests run by this class and its superclasses.
  # DO NOT OVERRIDE THIS UNLESS YOU KNOW WHAT YOU ARE DOING!
  sub list_tests {
      ...

Maybe that comment could be more helpful...  8-/

> It works as expected. What do you think? Am I missing something?

Well it could be that you are missing something.  If you try to avoid
using side effects from each test, then the order should not matter.

I suppose one day the tests may be run in parallel.  That would be
neat, and it would also be incompatible with explicit test ordering.


Matthew  #8-)

Re: [Perlunit-users] Died?

[Dmitry D. <dd...@ic...>]

Matthew Astley wrote:
> 
> On Sat, Oct 04, 2003 at 12:17:33PM +0400, Dmitry Diskin wrote:
> 
> 
>>sub test_000_scalar {
>>    my $self = shift;
>>    $self->assert(scalar(undef), 0);
>>}
> 
> 
>>This test faild with 'Died' message:
> 
> 
> Assert takes a boolean and an optional error message.  The boolean
> 'scalar(undef)' is false, so the assertion fails.  The message is
> plain '0' in this case, which is fine until the stringify method in
> Test::Unit::Exception says (line 35)
> 
>     my $message = $self->text || 'Died';
> 
> ...but "0" would be no more informative anyway.
> 
> 
>>Can you explain this? Where exactly the exception is?
> 
> 
> Does that help?

Yes, absolutely. Thanks.

-- 
Dmitry.

P.S. I have posted a bunch of other questions.. :)

Re: [Perlunit-users] How to exit from test suite?

[Matthew A. <mc...@us...>]

On Sat, Oct 04, 2003 at 01:16:08PM +0400, Dmitry Diskin wrote:

> If one of my tests fail,

One particular test, or any of them?  Tests are often considered to be
independent, at least to a large extent.

> other tests should not be executed. In order to stop execution, I
> use the following code:
> 
> sub test_001_load {

On the choice of method name, is the numbering just for convenience or
were you relying on one test's side-effects to do something for the
next one?  The manpage for Test::Unit::TestCase (notes section) talks
about this a bit.

>     my $self = shift;
>     if ($loaded_nok) {
>         $self->fail("Unrecoverable error, can't continue.");
>         exit;
>     }
> }

I haven't done anything like this with perlunit, but in JUnit running
from an Ant file, I have put aside a set of tests to run first.  They
check things like the presence of the database we're just about to run
the hundred tests against - 100 failures aren't very useful.

You could do this by generating test suites by some means and having a
more customised testrunner script.

> Is it a proper way? Is there any $suite->stop method?

Hmm, there's a Test::Unit::Result->stop() which would appear to do
what you want.  I'm not sure what the proper answer is, and I don't
claim to have read the docs recently.  8-}

You'd need to get the 'result' object from the 'suite' which creates
it.  $testrunner->result()->stop() would work, but this is probably a
"dirty" solution.

A neater way might be to register a Test::Unit::Listener (I haven't
tried) and use the add_failure event to fish the Result object out
from the failure exception?


Remember, there's more than one way to do it!

Matthew  #8-)

Re: [Perlunit-users] Died?

[Matthew A. <mc...@us...>]

Sorry for the late reply.  Been on holiday, it's a fair excuse for a
change.  8-)

I'm using the Debianised "libtest-unit-perl" v0.24-1.  (Thanks for
that Stephen, if you're listening.  There was a time when I intended
to do this myself, but then I went away from testing Perl for quite a
while.)


On Sat, Oct 04, 2003 at 12:17:33PM +0400, Dmitry Diskin wrote:

> sub test_000_scalar {
>     my $self = shift;
>     $self->assert(scalar(undef), 0);
> }

> This test faild with 'Died' message:

Assert takes a boolean and an optional error message.  The boolean
'scalar(undef)' is false, so the assertion fails.  The message is
plain '0' in this case, which is fine until the stringify method in
Test::Unit::Exception says (line 35)

    my $message = $self->text || 'Died';

...but "0" would be no more informative anyway.

> Can you explain this? Where exactly the exception is?

Does that help?


Matthew  #8-)

[Perlunit-users] Bugreport: wrong is_numeric() routne

[Dmitry D. <dd...@ic...>]

Hi All

Accidentally I've found a bug in Assert.pm:

     my ($expected, $actual) = ('1foo', '1bar');
     $self->assert_equals($expected, $actual);

The code above will not generate a failure. I traced module source, and 
found that the reason is in is_numeric():

sub is_numeric {
     my $str = shift;
     local $^W;
     return defined $str && ! ($str == 0 && $str !~ /[+-]?0(e0)?/);
}

for (qw(123foo 123 foo)) {
     print "$_ is numeric\n" if is_numeric($_) ;
}

__OUTPUT__
123foo is numeric
123 is numeric

At the same time, assert_str_equals does it's job.

Best regards,
Dmitry.

Re: [Perlunit-users] Designing tests

[Dmitry D. <dd...@ic...>]

Joi Ellis wrote:

> On Sun, 21 Sep 2003, Dmitry Diskin wrote:
> 
> 
>>Hello All
>>
>>I have to design unit tests for large OO application (yes, next time we 
>>will create tests before coding). But which is the best way to organize 
>>tests?
>>
>>In the Test::Unit distribution I saw 't' directory with 'head' scripts 
>>(all_tests.t, assert.t) and 'tlib' directory with nested class directories.
> 
> 
> That's the perl/CPAN test scripting used during the 
>   make;make test;make install
> process used for installing perl modules.  They aren't unit tests in the
> strict sense, but could be written that way.  I don't use them for
> actual unit tests.
> 
> Test::Unit is based more on JUnit ideas and is easier to adapt to.
> 
> You can get a lot of basic test philosophy from the junit.org site:
> http://www.junit.org/index.htm
> 
> Here is another good site:
> http://www.xprogramming.com/
> 
> The downloads page there has links to several Perl test tools.
> 
> How you organize your tests depends a lot on what language you're using
> and if you intend to include the tests with the product, or exclude them.
> In Java, I'll create a top-level tests directory and duplicate the
> class tree there, ie:
> 
>   tests/foo/bar
>   tests/foo/baz
>   src/foo/bar
>   src/foo/baz
> 
> that way when I compile src, the tests aren't written to the classes
> path, and the tests are excluded from the final product.
> 
> If it's an opensource project, then I use:
>   src/foo/bar
>   src/foo/bar/tests
>   src/foo/baz
>   src/foo/baz/tests
> 
> and then classes gets the tests and so do the user/developers.
> 
> It all just depends on what you need to do with the test code and how
> the language works.  There is no one right answer.
> 
> PS: I'm only online on the weekends, 'cause I got laid off last year and
> resorted to driving trucks for a living because I couldn't get a perl/java
> job in Minnesota.
> 
> I'm using perl unit these days, using a little front-end of my own and some
> customization of runonetest.pl to make it spit out html.  I use mozilla as
> my GUI now.  I haven't looked at RUI yet but it sounds interesting.
> 

Thank you very much for your answer. I decided to create 'tests' 
directories under each class and subclass directory (the same way it is 
done in RUI project):

src/foo/
src/foo/tests
src/foo/bar
src/foo/bar/tests
src/foo/baz
src/foo/baz/tests

Each tests subdirectory contain AllTests.pm and, optionally, TestCase.pm 
(if a class does not have TestCase.pm, in uses one from it's parent 
class). Sample data for tests goes to 'data' subdirectory of 
corresponding 'tests' directory.

I have plans to subclass TestRunner class and create 'CGITestRunner'. 
The main idea is to be able to show tests as a tree, and to let user to 
check any combination of testSuites to be run, and to show results in 
HTML. If you can share your code here -- please do, it is interesting to 
look at it.

Thanks again, and good luck!

-- 
Dmitry.

Re: [Perlunit-users] Designing tests

[Joi E. <gy...@vi...>]

On Sun, 21 Sep 2003, Dmitry Diskin wrote:

> Hello All
> 
> I have to design unit tests for large OO application (yes, next time we 
> will create tests before coding). But which is the best way to organize 
> tests?
> 
> In the Test::Unit distribution I saw 't' directory with 'head' scripts 
> (all_tests.t, assert.t) and 'tlib' directory with nested class directories.

That's the perl/CPAN test scripting used during the 
  make;make test;make install
process used for installing perl modules.  They aren't unit tests in the
strict sense, but could be written that way.  I don't use them for
actual unit tests.

Test::Unit is based more on JUnit ideas and is easier to adapt to.

You can get a lot of basic test philosophy from the junit.org site:
http://www.junit.org/index.htm

Here is another good site:
http://www.xprogramming.com/

The downloads page there has links to several Perl test tools.

How you organize your tests depends a lot on what language you're using
and if you intend to include the tests with the product, or exclude them.
In Java, I'll create a top-level tests directory and duplicate the
class tree there, ie:

  tests/foo/bar
  tests/foo/baz
  src/foo/bar
  src/foo/baz

that way when I compile src, the tests aren't written to the classes
path, and the tests are excluded from the final product.

If it's an opensource project, then I use:
  src/foo/bar
  src/foo/bar/tests
  src/foo/baz
  src/foo/baz/tests

and then classes gets the tests and so do the user/developers.

It all just depends on what you need to do with the test code and how
the language works.  There is no one right answer.

PS: I'm only online on the weekends, 'cause I got laid off last year and
resorted to driving trucks for a living because I couldn't get a perl/java
job in Minnesota.

I'm using perl unit these days, using a little front-end of my own and some
customization of runonetest.pl to make it spit out html.  I use mozilla as
my GUI now.  I haven't looked at RUI yet but it sounds interesting.

-- 
Joi Ellis                    
gy...@vi...

No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried.  Anything
that kicks a monopoly in the pants has got to be good for something.
           - Chris Johnson

[Perlunit-users] Nobody here?

[Dmitry D. <dd...@ic...>]

Hi poeople!

It's very strange to see noone answering my questions here...  Where are 
you?

-- 
Dmitry.

[Perlunit-users] How to exit from test suite?

[Dmitry D. <dd...@ic...>]

Hi All!

If one of my tests fail, other tests should not be executed. In order to 
stop execution, I use the following code:

sub test_001_load {
     my $self = shift;
     if ($loaded_nok) {
         $self->fail("Unrecoverable error, can't continue.");
         exit;
     }
}

Is it a proper way? Is there any $suite->stop method?

-- 
Dmitry.

[Perlunit-users] Died?

[Dmitry D. <dd...@ic...>]

Hi All!

sub test_000_scalar {
     my $self = shift;
     $self->assert(scalar(undef), 0);
}

This test faild with 'Died' message:

There was 1 failure:
1) tests.pm:10 - test_000_scalar(tests)
Died

Can you explain this? Where exactly the exception is?

-- 
Thanks,
Dmitry.

[Perlunit-users] Using @TESTS for changing tests execution order

[Dmitry D. <dd...@ic...>]

Hi All!

I read from TestCase.pm POD that one can populate @TESTS array in order 
to specify the desired order of tests execution:

### quote begin

If you need to specify the test order, you can do one of the
following:

=over 4

=item * Set @TESTS

   our @TESTS = qw(my_test my_test_2);

This is the simplest, and recommended way.

### quote end

But the above does not work for me. I can include only desired tests 
using @TESTS, but they are listed and executed in a random order, 
although I name them as test_001_foo, test_oo2_bar, etc. I think that 
the reason is in the following return statement (line 114 of TestCase.pm):

     return keys %tests;

I decided to override list_tests method like this:

sub list_tests {
     my $self = shift;
     return sort $self->SUPER::list_tests(@_);
}

It works as expected. What do you think? Am I missing something?

Thanks
Dmitry.

[Perlunit-users] Remote User Interface - a thin-client widget library in JavaScript

[Phlip <pl...@sy...>]

Dmitry Diskin wrote:

> I have to design unit tests for large OO application (yes, next time we
> will create tests before coding). But which is the best way to organize
> tests?
>
> In the Test::Unit distribution I saw 't' directory with 'head' scripts
> (all_tests.t, assert.t) and 'tlib' directory with nested class
directories.
>
> I have found also an application that uses Test::Unit - it is Rui -
> Remote User Interface (http://www.cortext.co.il). I downloaded it and
> saw another approach: each class directory has 'tests' subdirectory,
> which contains AllTests.pm file looking like this:
>
> use Test::Unit::TestSuite;
>
> use Rui::Event::tests::AllTests;
> use Rui::Model::tests::AllTests;
> use Rui::Widget::tests::AllTests;
> use Rui::View::tests::AllTests;
>
> sub new { bless {}, shift }
>
> sub suite {
> my $suite = Test::Unit::TestSuite->empty_new("Rui");
> $suite->add_test(Rui::Event::tests::AllTests->suite);
> $suite->add_test(Rui::Model::tests::AllTests->suite);
> $suite->add_test(Rui::Widget::tests::AllTests->suite);
> $suite->add_test(Rui::View::tests::AllTests->suite);
> return $suite;
> }
>
> Thus, it adds tests for child classes, and they may add more child tests
> as well. Then all tests are called by runing
>
> use Test::Unit::TestRunner;
> my $testrunner = Test::Unit::TestRunner->new;
> $testrunner->start(@ARGV);
>
> , where @ARGV is tests::AllTests, forr example.
>
> Do you see any drawbacks of this approach? Can you recommend other
> sample material available on the Net?

D, this is a good question, however...

...Rui, at http://www.cortext.co.il , has me slack-jawed.

Everyone on this mailing list needs to explore this project. It's doing
exactly what we have been talking about!

This light GUI Toolkit - written & tested in Perl, Java & JavaScript by Ran
Eliam and hosted at http://cortext.co.il/ - is a magnificent example of
these solutions:

 - Test-first, with tests on both the server and client
 - Duplication between the server and client resolved
 - Seamless client-side experience, without fetching pages
 - Client-side widgets via Model View Controller.

A product that stretches languages' abilities so far (Perl to serve Web
pages, JavaScript to paint widgets, etc.) is often too fragile. But tests
keep this product robust.

The only downside is the product requires Internet Explorer 6. But
remember - in theory, to port to another browser, one need only get the
JavaScript tests to pass.

Also, can anyone help D with his question? ;-)

--
  Phlip
    http://www.greencheese.org/GonzoFriday

[Perlunit-users] Designing tests

[Dmitry D. <dd...@ic...>]

Hello All

I have to design unit tests for large OO application (yes, next time we 
will create tests before coding). But which is the best way to organize 
tests?

In the Test::Unit distribution I saw 't' directory with 'head' scripts 
(all_tests.t, assert.t) and 'tlib' directory with nested class directories.

I have found also an application that uses Test::Unit - it is Rui - 
Remote User Interface (http://www.cortext.co.il). I downloaded it and 
saw another approach: each class directory has 'tests' subdirectory, 
which contains AllTests.pm file looking like this:

use Test::Unit::TestSuite;

use Rui::Event::tests::AllTests;
use Rui::Model::tests::AllTests;
use Rui::Widget::tests::AllTests;
use Rui::View::tests::AllTests;

sub new { bless {}, shift }

sub suite {
	my $suite = Test::Unit::TestSuite->empty_new("Rui");
	$suite->add_test(Rui::Event::tests::AllTests->suite);
	$suite->add_test(Rui::Model::tests::AllTests->suite);
	$suite->add_test(Rui::Widget::tests::AllTests->suite);
	$suite->add_test(Rui::View::tests::AllTests->suite);
	return $suite;
}

Thus, it adds tests for child classes, and they may add more child tests 
as well. Then all tests are called by runing

use Test::Unit::TestRunner;
my $testrunner = Test::Unit::TestRunner->new;
$testrunner->start(@ARGV);

, where @ARGV is tests::AllTests, forr example.

Do you see any drawbacks of this approach? Can you recommend other 
sample material available on the Net?

Thanks.
-- 
Dmitry

Re: [Perlunit-users] Web GUI for running tests

[Dmitry D. <dd...@ic...>]

chromatic wrote:

> On Thursday, September 18, 2003, at 11:25 AM, Phlip wrote:
> 
>>> Did anybody see a piece of software (perl CGI) which will allow to
>>> display a set of tests on a web page, select tests to be run, and see
>>> their results after submitting? Ideally this software should use
>>> Test::Unit, of course. :)
>>
>>
>> Other than http://fitnesse.org ?
> 
> 
> There's Test::FIT.
> 

Bret, chromatic - thanks.

-- 
Dmitry

Re: [Perlunit-users] Web GUI for running tests

[Bret P. <br...@pe...>]

At 01:15 PM 9/18/2003, Dmitry Diskin wrote:
>Did anybody see a piece of software (perl CGI) which will allow to display 
>a set of tests on a web page, select tests to be run, and see their 
>results after submitting? Ideally this software should use Test::Unit, of 
>course. :)

Something along these lines is Fit, which has a perl port.

http://search.cpan.org/src/INGY/Test-FIT-0.11/example/Test-FIT.html

Bret



_____________________________________
  Bret Pettichord, Software Tester
    Book - www.testinglessons.com
    Consulting - www.pettichord.com
    Blog - www.io.com/~wazmo/blog
    Hotlist - www.testinghotlist.com

Re: [Perlunit-users] Web GUI for running tests

[chromatic <chr...@wg...>]

On Thursday, September 18, 2003, at 11:25 AM, Phlip wrote:

>> Did anybody see a piece of software (perl CGI) which will allow to
>> display a set of tests on a web page, select tests to be run, and see
>> their results after submitting? Ideally this software should use
>> Test::Unit, of course. :)
>
> Other than http://fitnesse.org ?

There's Test::FIT.

-- c

Re: [Perlunit-users] Web GUI for running tests

[Dmitry D. <dd...@ic...>]

Phlip wrote:

>>Did anybody see a piece of software (perl CGI) which will allow to
>>display a set of tests on a web page, select tests to be run, and see
>>their results after submitting? Ideally this software should use
>>Test::Unit, of course. :)
> 
> 
> Other than http://fitnesse.org ?
> 
> Warning: It requires in-your-sleep knowledge of both Java and FIT, both of
> which are slightly...obese.
> 
> (Not like our lustrous Perl!;)
> 

Wow! Looking at it right now. Thanks.

-- 
Dmitry.

Re: [Perlunit-users] Web GUI for running tests

[Phlip <pl...@sy...>]

> Did anybody see a piece of software (perl CGI) which will allow to
> display a set of tests on a web page, select tests to be run, and see
> their results after submitting? Ideally this software should use
> Test::Unit, of course. :)

Other than http://fitnesse.org ?

Warning: It requires in-your-sleep knowledge of both Java and FIT, both of
which are slightly...obese.

(Not like our lustrous Perl!;)

--
  Phlip
    http://www.greencheese.org/HoneySatellite

[Perlunit-users] Web GUI for running tests

[Dmitry D. <dd...@ic...>]

Hi All!

Did anybody see a piece of software (perl CGI) which will allow to 
display a set of tests on a web page, select tests to be run, and see 
their results after submitting? Ideally this software should use 
Test::Unit, of course. :)

Best regards,
Dmitry.

Re: [Perlunit-users] Testing module validity with test::Unit

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

Dmitry Diskin (dd...@ic...) wrote:
> Adam Spiers wrote:
> >Dmitry Diskin (dd...@ic...) wrote:
> >
> >>Hello All!
> >>
> >>>From the Test::More documentation I learned about use_ok() and 
> >>require_ok() test functions. They recommend to use them as follows:
> >>
> >> BEGIN { use_ok('Some::Module') }
> >> BEGIN { ...some code that depends on the use... }
> >>
> >>In the case of failure to 'use' some module test will report it. Is 
> >>there any way (or need?) to do something similar with Test::Unit? Say, I 
> >>want to test my class methods, but the whole module is broken. I will 
> >>get standard perl compile error in that case?
> >
> >
> >It's been a long time since I looked at it, but I think you probably
> >should see errors - ISTR working on Test::Unit::Loader to make sure
> >the right errors were generated.  Have a look at that module, and
> >quite simply try it and see what happens!
> 
> Thank you for replying. I'm not sure if I can handle it myself. I looked 
> to Test::Unit::Loader and did not find any suitable method. Probably it 
> is not needed to test module loading at all, because if it doesn't load, 
> no tests can be run on it?

That's right.  When I said "try it and see", I meant: try running some
tests on a module which has (say) syntax errors.  Hopefully
T::U::Loader will spot the compile failure and your test runner will
show it.

> BTW, your answer came from ad...@sp... - no sign of mailing list 
> here. I was thinking that since I wrote to maillist, discussion thread 
> should be there as well..

Whoops, pressed the wrong button.  Am now cc'ing to list.