perlunit-users

[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

[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

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

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.