[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