On 8/26/05, Rob Nagler <nagler@...> wrote:
>  Our list seems to be growing all of a sudden.  Is there a upswing in
>  the use of Perl around the world or XP?

I think it's more that there's an upsurge in understand that XP applies to Perl.

Rob

I can't speak for anyone else, but I recently joined the list. I began
my professional career in 1998 writing Perl programs for the web. Then,
in late 2001, the company I was working for decided to standardize on
Java. I have long since moved on, but I've had my ass firmly planted in
J2EE-land ever since. For the last couple of years I've had the pleasure
of doing full blown XP in a Java environment.

Recently, I've been doing freelance consulting, and I've been hired to
write some native code in C/C++. I knew that I was going to test drive
it, but I was unfamiliar with the test frameworks available. I gave
several a try (CppUnit, CxxUnit, TUX, ...at least one other...) but they
all sucked royally. Then it occured to me that I could test my native
code from Perl. So, I started writing tests first in Perl. Most of the
time I'd use Inline::* or I might black-box with exec() depending on the
granularity of the test. Then I could implement the C/C++/Assembly code
to pass the test.

It also occured to me right away that I hate writing make files, but I
could use Perl to configure and build (Rather than Ant or NAnt, which I
am used to, but they are unwieldy when all you are doing is calling
shell commands.)

Anyway, when I found myself doing XP practices with Perl it seemed like
a natural thing to look for others who were doing the same so I found
this list.

...

Another thought: OReilly just published "Perl Testing" (Which,
ironically, talks about testing C code with Inline:* even though I did
it before I read the book) recently. That might have sparked some
additional interest.

Thanks,
Adam

Rob Nagler wrote:

>Our list seems to be growing all of a sudden.  Is there a upswing in
>the use of Perl around the world or XP?
>
>Cheers,
>Rob
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>.
>
>
>

Rob Kinyon wrote:
> On 8/26/05, Rob Nagler <nagler@...> wrote:
>
>> Our list seems to be growing all of a sudden.  Is there a upswing in
>> the use of Perl around the world or XP?
>
> I think it's more that there's an upsurge in understand that XP applies to
Perl.

Of course, it might just be that you were linked to from this week's new
perl.com article.

Dave...

Dave Cross writes:
> Of course, it might just be that you were linked to from this week's new
> perl.com article.

Must be.  We had at +10 sign ups today.  PR adds value.

Rob

Here's the URL of the article - link to this group is on the last page.

    http://perl.com/pub/a/2005/08/25/tools.html

J Matisse Enzer writes:
>    http://perl.com/pub/a/2005/08/25/tools.html

Nice article.

Rob

That article is how I found out about extreme perl.
--
Alan


[Non-text portions of this message have been removed]

On Aug 27, 2005, at 9:26 AM, Alan Young wrote:

> That article is how I found out about extreme perl.
>
Cool :-)

Not sure what unit tester you all use, but I wrote one that seems pretty
good (so far).

Its main claim to fame is it that it automatically detects test cases and
executes them, i.e. no test suites and keeping them up to date etc.

http://arrizza.com/unittesters/utperl/utperl.html

John

I just use Test::More and prove. Why reinvent the wheel?

cpp gent wrote:

>Not sure what unit tester you all use, but I wrote one that seems pretty
>good (so far).
>
>Its main claim to fame is it that it automatically detects test cases and
>executes them, i.e. no test suites and keeping them up to date etc.
>
>http://arrizza.com/unittesters/utperl/utperl.html
>
>John
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>.
>
>
>

>From: Adam Sroka <adam.s@...>
>I just use Test::More and prove. Why reinvent the wheel?

Depends on the wheel.

Right. TMTOWDI applies. But what is it about the de facto standard wheel
that you don't like? I read your code, and I don't see any advantage.
Enlighten me.

cpp gent wrote:

>>From: Adam Sroka <adam.s@...>
>>I just use Test::More and prove. Why reinvent the wheel?
>>
>>
>
>Depends on the wheel.
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>.
>
>
>

Adam Sroka writes:
> Right. TMTOWDI applies. But what is it about the de facto standard wheel
> that you don't like? I read your code, and I don't see any advantage.
> Enlighten me.

It's, like, very, ok, repeatitive, ok?  Test::* and xUnit need a
refactoring so that you only express what is the essence of the
cases.  They are also weak on the deviance side.

Send a test here, and I'll show you how it can be refactored to say
more with less.

Rob

On 8/29/05, Rob Nagler <nagler@...> wrote:
>  Adam Sroka writes:
>  > Right. TMTOWDI applies. But what is it about the de facto standard wheel
>  > that you don't like? I read your code, and I don't see any advantage.
>  > Enlighten me.
>
>  It's, like, very, ok, repeatitive, ok?  Test::* and xUnit need a
>  refactoring so that you only express what is the essence of the
>  cases.  They are also weak on the deviance side.

Please explain more about what you mean "weak on the deviance side". I
tend to test my failure cases using mocked objects and subroutines,
which means the tests are positive tests, not negative ones.

As for the repetitive nature ... I look at it as the difference
between ASM and Perl. Test::* is ASM, but ASM is very simple to prove
correctness for. The last thing I want is a bug in my testsuite
horking up my results. The more complicated the testing
infrastructure, the more likely bugs will appear.

Rob

Yup.  Not seeing  anything that the Test::Builder modules +
Test::Class or Test::Unit give.

Adrian


On 29 Aug 2005, at 05:30, Adam Sroka wrote:

> Right. TMTOWDI applies. But what is it about the de facto standard
> wheel
> that you don't like? I read your code, and I don't see any advantage.
> Enlighten me.
>
> cpp gent wrote:
>
>
>>> From: Adam Sroka <adam.s@...>
>>> I just use Test::More and prove. Why reinvent the wheel?
>>>
>>>
>>>
>>
>> Depends on the wheel.
>>
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>> .
>>
>>
>>
>>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Fair play? Video games influencing politics. Click and talk back!
> http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/NhFolB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

On 29 Aug 2005, at 14:21, Rob Nagler wrote:

> Adam Sroka writes:
>
>> Right. TMTOWDI applies. But what is it about the de facto standard
>> wheel
>> that you don't like? I read your code, and I don't see any advantage.
>> Enlighten me.
>
> It's, like, very, ok, repeatitive, ok?

I'm reading that as not liking seeing lots of "ok BLAH" statements in
the test output - in which case just write a test runner that doesn't
show them.

I agree that there are numerous ways that test runners could get more
useful in Perl.

Or do you mean something else?

> Test::* and xUnit need a
> refactoring so that you only express what is the essence of the
> cases.

If I see duplication in my tests I refactor it. Often making lots of
little domain specific Test::* modules.

> They are also weak on the deviance side.

Can you explain what you mean here?

> Send a test here, and I'll show you how it can be refactored to say
> more with less.

-----
#! /usr/bin/perl

use strict;
use warnings;
use Our::Test::HTML::HouseStyle qw( style_ok );
use Our::Test::Config qw( html_files );
use Our::Test::Utils qw( test_all );

test_all { style_ok( $_ ) } html_files();
-----

Cheers,

Adrian

Adrian Howard writes:
> I'm reading that as not liking seeing lots of "ok BLAH" statements in
> the test output - in which case just write a test runner that doesn't
> show them.

No, I don't like typing them. :-)

> If I see duplication in my tests I refactor it. Often making lots of
> little domain specific Test::* modules.

Yes, that's what we do, too, but the structure is missing to allow for
easy refactoring.

> Can you explain what you mean here?

Here's a simple comparison:

     use strict;
     use Test::More tests => 5;
     use Test::Exception;
     BEGIN {
	 use_ok('EMA');
     }
     dies_ok {EMA->new(-2)};
     dies_ok {EMA->new(0)};
     lives_ok {EMA->new(1)};
     dies_ok {EMA->new(2.5)};

in Bivio::Test this would be:

     use strict;
     use Bivio::Test;
     Bivio::Test->new('EMA')->unit([
	 EMA => [
	     new => [
		 -2 => Bivio::DieCode->DIE,
		 0 => Bivio::DieCode->DIE,
		 1 => undef,
		 2.5 => Bivio::DieCode->DIE,
	     ],
	 ],
     ]);

Note the difference.  In the Test::More case, I need to specify the
number of tests.  In Bivio::Test, the infrastructure counts the test
for me.  I have to import Test::More and Test::Exception.  These
should be one module.

You must repeat dies_ok even though it gives no new information.  Just
like the lives_ok.

use_ok is repeated.  Every test imports a class.  The BEGIN is
redundant.

dies_ok is insufficient.  The lack of explicit exceptions causes more
problems in complex examples such as DB testing, where you need to
test for constraint violations, database errors, and such.

The tests => 5 is a denormalization.  I can count the number of
tests.  The use_ok shouldn't even be a test case.  If it doesn't
import, you've got bigger problems.

The essence of the problem is that Test::More and friends are
imperative, and Bivio::Test is declarative.  Bivio::Test can count the
cases, and it does.  Bivio::Test is 340 NCLOC in 31 subs.  Test::More
is 230 NCLOC in 26 subs.  That's a small price to pay for reducing the
number of concepts in my tests.

> #! /usr/bin/perl
>
> use strict;
> use warnings;
> use Our::Test::HTML::HouseStyle qw( style_ok );
> use Our::Test::Config qw( html_files );
> use Our::Test::Utils qw( test_all );
>
> test_all { style_ok( $_ ) } html_files();

Note the redundancies.  test_all x 2, style_ok x 2, and test_all x 2;
qw() is twice.  There are three "use".  use warnings should be set by
the test infrastructure or the #! line.  Here's how I would refactor
the test:

     #!perl -w
     use strict;
     use Our::Test::HTML::HouseStyle;
     Our::Test::HTML::HouseStyle->test_all(
	 'Our::Test::Config',
	 'html_files',
     );

I would say that "style_ok" is implicit.  That's what HouseStyle tells
me.  Our::Test::HTML::HouseStyle should subclass Our::Test::Utils.
Our::Test::Utils should load the class under test (first arg) and
call "html_files" on it.

package Our::Test::HTML::HouseStyle;

use base(Our::Test::Utils);
sub test_all {
     my($proto, $class, $method, $args, $validator) = @_;
     $args ||= [];
     # This assumes HouseStyle has multiple validators
     $validator ||= 'style_ok';
     return $proto->SUPER::test_all(
         sub {
    	     return $proto->$validator(@_);
	 },
    	 [Bivio::IO::ClassLoader->simple_require($class)->$method(@$args)],
     );
}

package Our::Test::Utils;

sub test_all {
     my($proto, $validator, $values) = @_;
     my($i) = 0;
     $proto->print('1..',  @$values);
     foreach my $v (@$values) {
          my($ok);
          my($die) = Bivio::Die->catch(sub {$ok = $validator->($v)});
       	  Bivio::IO::Alert->warn($v, ': invalid value',
	      $die ? ('; died ', $die) : ())
	      unless $ok;
	  $proto->print(!$ok && 'not ', 'ok ', ++$i, "\n");
     }
}

Why use Bivio::IO::Alert->warn?  Well, if $v is very large, it will
truncate it to a configurable value.  If $v is a ref, it'll
recursively dump the value (only so far, again configurable).  It
calls ->as_string if the object can('as_string').  $die contains
interesting information such as the entity that caused the exception,
the line, the stack trace, etc.  It's all managed for me.  I can
control the output with a simple configuration file.

I could go on, but the point is that the tests should be as short as
possible with as few extraneous concepts (boilerplate) as possible so
that people won't have any excuses not to test.  If I have to remember
to import three separate classes to test my styles, I'm going to get
frustrated and not right the test.  Moreover, it's likely I've copied
the file multiple times, which breaks OAOO and the Rule of Three.

Rob

Rob Kinyon writes:
> Please explain more about what you mean "weak on the deviance side". I
> tend to test my failure cases using mocked objects and subroutines,
> which means the tests are positive tests, not negative ones.

I'm not a big fan of Mock objects.  I only use them when it's
absolutely necessary.  I like end-to-end tests, even our unit tests
hit the database.

> As for the repetitive nature ... I look at it as the difference
> between ASM and Perl. Test::* is ASM, but ASM is very simple to prove
> correctness for.

I assume you mean Assembler by ASM.  I hypothesize the shorter the
theory, the easier the proof.

> The last thing I want is a bug in my testsuite
> horking up my results. The more complicated the testing
> infrastructure, the more likely bugs will appear.

The shorter the tests, the fewer the number of bugs.  By encapsulating
repetition through declarative programming, we not only can prove
certain aspects of the test structure automatically.  Let's go back to
the EMA example:

     use strict;
     use Test::More tests => 2;
     use Test::Exception;
     BEGIN {
         use_ok('EMA');
     }
     dies_ok {EMA->new(-2)};

Suppose I do this:

     use strict;
     use Test::More tests => 2;
     use Test::Exception;
     BEGIN {
         use_ok('SMA');
     }
     dies_ok {EMA->new(-2)};

And suppose I had copied the SMA test to make the EMA test, because
it's so verbose that I find copy-and-paste faster.  The above test
will pass, incorrectly.  However, let's look at what Bivio::Test does:

     use strict;
     use Bivio::Test;
     Bivio::Test->new('SMA')->unit([
         EMA => [
	     new => [
	         -2 => Bivio::DieCode->DIE,
	     ],
	 ],
     ]);

This test will fail.  The SMA import will pass, but the create_object
will fail (SMA->new('EMA') does not return a valid object, and in
fact, dies).  The infrastructure does not pass the case silently.
Instead, it explains to me why the case failed, that is, because there
was no valid object to test.

The danger of simple -- as in repetitive -- is that there are more
components for the human eye to validate.   By programming
declaratively, I create complex infrastructure for repetitive tasks,
and use them repetitively.  If testing were a "one off", I wouldn't do
this.  However, the Rule of Three applies in spades when it comes to
testing, and Perl gives you some extremely powerful tools to eliminate
repetition.

Rob

Rob Nagler wrote:

>Here's a simple comparison:
>
>    use strict;
>    use Test::More tests => 5;
>    use Test::Exception;
>    BEGIN {
> use_ok('EMA');
>    }
>    dies_ok {EMA->new(-2)};
>    dies_ok {EMA->new(0)};
>    lives_ok {EMA->new(1)};
>    dies_ok {EMA->new(2.5)};
>
>in Bivio::Test this would be:
>
>    use strict;
>    use Bivio::Test;
>    Bivio::Test->new('EMA')->unit([
> EMA => [
>     new => [
>  -2 => Bivio::DieCode->DIE,
>  0 => Bivio::DieCode->DIE,
>  1 => undef,
>  2.5 => Bivio::DieCode->DIE,
>     ],
> ],
>    ]);
>
>
>
You make several good points, but it seems to me like you are throwing
out the baby with the bath water.

I never declare the number of units. A "best practice" to someone is a
silly, waste of time to someone else. However, instead of writing my own
test framework:

use Test::More qw(no_plan);

Works just fine for me.

I don't like use_ok() that much either. Since I am test driving, it is
enough that the test fails if it can't find the class under test. This
will not compile ("Can't locate Does_Not_Exist.pm in @INC..."):

use strict;
use warnings;
use Does_Not_Exist;

That works for me too. I suppose I like it because it is the same way I
would do it in another language like Java (or C#). This doesn't compile
in Java:

import org.testng.annotations.*;
import org.obnoxiously.long.package.name.DoesNotExist;

public class StuffTest {
     ...
}


The semantic difference between your code snippets above seems to be
that you are encapsulating your unit tests in an object. If you come
from an xUnit language like Smalltalk, Java, or C#, then you do this
because you have no choice (Everything HAS to be encapsulated by an
object in those languages.) Since we don't HAVE to do that, the question
becomes, why would we want to? I wouldn't. You'll have to explain why
you would.

I wouldn't because I think that the nature of testing is procedural, so
testing procedurally until I have an idea that smells like an object
feels like the right thing to do. Once I have an idea that feels like it
needs to be an object, then I make one. That is the essence of XP - do
the simplest thing that could possibly work. Most unit tests in other
languages feel like procedures wrapped in classes anyway (e.g. TestCase
feels more like a collection of testThis() methods than a proper class.)

Your code is every bit as repetitive as the code you are replacing. The
difference is that you've dropped in a layer of abstraction
(unnecessarily, IMO) between your repetitive test code and the main
package. Test code is repetitive because testing is repetitive. You can
hide that, but you haven't changed it.

On 8/29/05, Rob Nagler <nagler@...> wrote:
>  Rob Kinyon writes:
>  > Please explain more about what you mean "weak on the deviance side". I
>  > tend to test my failure cases using mocked objects and subroutines,
>  > which means the tests are positive tests, not negative ones.
>
>  I'm not a big fan of Mock objects.  I only use them when it's
>  absolutely necessary.  I like end-to-end tests, even our unit tests
>  hit the database.

That is a personal preference. I prefer mocks, because it allows me to
test in isolation. My theory is that perfect components will work
together perfectly. It also forces me to work out my APIs a lot
sooner. This means that I can refactor with confidence.

>  > As for the repetitive nature ... I look at it as the difference
>  > between ASM and Perl. Test::* is ASM, but ASM is very simple to prove
>  > correctness for.
>
>  I assume you mean Assembler by ASM.  I hypothesize the shorter the
>  theory, the easier the proof.

Unfortunately, that doesn't work out in real life. I have only to
point to the Riemann Hypothesis. (There is no X^n + Y^n = Z^n, X, Y,
Z, and n being integers where n > 2.) The proof took 400 years, 300M
IQ points, and about 200 pages to accomplish.

>  The danger of simple -- as in repetitive -- is that there are more
>  components for the human eye to validate.   By programming
>  declaratively, I create complex infrastructure for repetitive tasks,
>  and use them repetitively.  If testing were a "one off", I wouldn't do
>  this.  However, the Rule of Three applies in spades when it comes to
>  testing, and Perl gives you some extremely powerful tools to eliminate
>  repetition.

Absolutely. And, I do refactor my tests. However, I focus primarily on
refactoring my code so that I need fewer tests overall. If I can test
the same functionality with fewer tests by using cleaner APIs and mock
objects, isn't that also good?

Rob

Rob Kinyon wrote:

> >  I assume you mean Assembler by ASM.  I hypothesize the shorter the
> >  theory, the easier the proof.
>
>Unfortunately, that doesn't work out in real life. I have only to
>point to the Riemann Hypothesis. (There is no X^n + Y^n = Z^n, X, Y,
>Z, and n being integers where n > 2.) The proof took 400 years, 300M
>IQ points, and about 200 pages to accomplish.
>
You mean Fermat's  Last Theorem; according to
http://mathworld.wolfram.com/FermatsLastTheorem.html :  a theorem first
proposed by Fermat
<http://scienceworld.wolfram.com/biography/Fermat.html> ( 1601 - 1665 )
Eric Weisstein's World of Biography in the form of a note scribbled in
the margin of his copy of the ancient Greek text /Arithmetica/ by
Diophantus <http://scienceworld.wolfram.com/biography/Diophantus.html>
Eric Weisstein's World of Biography. The scribbled note was discovered
posthumously, and the original is now lost. However, a copy was
preserved in a book published by Fermat's son. In the note, Fermat
claimed to have discovered a proof that the Diophantine equation
<http://mathworld.wolfram.com/DiophantineEquation.html> x^n+y^n==z^n has
no integer <http://mathworld.wolfram.com/Integer.html> solutions for n>2
and x,y,z!=0.

According to Wolfram (
http://mathworld.wolfram.com/RiemannHypothesis.html ), Reimann's
Hypothesis ... First published by Riemann (1859), the Riemann hypothesis
states that the nontrivial Riemann zeta function zeros
<http://mathworld.wolfram.com/RiemannZetaFunctionZeros.html>, i.e., the
values of s other than -2, -4, -6, ... such that zeta(s)==0 (where
zeta(s) is the Riemann zeta function
<http://mathworld.wolfram.com/RiemannZetaFunction.html>) all lie on the
"critical line <http://mathworld.wolfram.com/CriticalLine.html>"
sigma==R[s]==1/2 (where R[s] denotes the real part
<http://mathworld.wolfram.com/RealPart.html> of s). While it was long
believed that Riemann's hypothesis was the result of deep intuition on
the part of Riemann
<http://scienceworld.wolfram.com/biography/Riemann.html> Eric
Weisstein's World of Biography, an examination of his papers by C. L.
Siegel showed that Riemann had made detailed numerical calculations of
small zeros of the Riemann zeta function
<http://mathworld.wolfram.com/RiemannZetaFunction.html> zeta(s) to
several decimal digits (Granville 2002; Borwein and Borwein 2003, p. 68).

Yeah, that one. :-)

On 8/29/05, Tom Legrady <legrady@...> wrote:
>
>
>
> Rob Kinyon wrote:
>
> > > I assume you mean Assembler by ASM. I hypothesize the shorter the
> > > theory, the easier the proof.
> >
> >Unfortunately, that doesn't work out in real life. I have only to
> >point to the Riemann Hypothesis. (There is no X^n + Y^n = Z^n, X, Y,
> >Z, and n being integers where n > 2.) The proof took 400 years, 300M
> >IQ points, and about 200 pages to accomplish.
> >
> You mean Fermat's Last Theorem; according to
> http://mathworld.wolfram.com/FermatsLastTheorem.html : a theorem first
> proposed by Fermat
> <http://scienceworld.wolfram.com/biography/Fermat.html> ( 1601 - 1665 )
> Eric Weisstein's World of Biography in the form of a note scribbled in
> the margin of his copy of the ancient Greek text /Arithmetica/ by
> Diophantus <http://scienceworld.wolfram.com/biography/Diophantus.html>
> Eric Weisstein's World of Biography. The scribbled note was discovered
> posthumously, and the original is now lost. However, a copy was
> preserved in a book published by Fermat's son. In the note, Fermat
> claimed to have discovered a proof that the Diophantine equation
> <http://mathworld.wolfram.com/DiophantineEquation.html> x^n+y^n==z^n has
> no integer <http://mathworld.wolfram.com/Integer.html> solutions for n>2
> and x,y,z!=0.
>
> According to Wolfram (
> http://mathworld.wolfram.com/RiemannHypothesis.html ), Reimann's
> Hypothesis ... First published by Riemann (1859), the Riemann hypothesis
> states that the nontrivial Riemann zeta function zeros
> <http://mathworld.wolfram.com/RiemannZetaFunctionZeros.html>, i.e., the
> values of s other than -2, -4, -6, ... such that zeta(s)==0 (where
> zeta(s) is the Riemann zeta function
> <http://mathworld.wolfram.com/RiemannZetaFunction.html>) all lie on the
> "critical line <http://mathworld.wolfram.com/CriticalLine.html>"
> sigma==R[s]==1/2 (where R[s] denotes the real part
> <http://mathworld.wolfram.com/RealPart.html> of s). While it was long
> believed that Riemann's hypothesis was the result of deep intuition on
> the part of Riemann
> <http://scienceworld.wolfram.com/biography/Riemann.html> Eric
> Weisstein's World of Biography, an examination of his papers by C. L.
> Siegel showed that Riemann had made detailed numerical calculations of
> small zeros of the Riemann zeta function
> <http://mathworld.wolfram.com/RiemannZetaFunction.html> zeta(s) to
> several decimal digits (Granville 2002; Borwein and Borwein 2003, p. 68).
>
>
>  SPONSORED LINKS
>   Software
jewelry<http://groups.yahoo.com/gads?t=ms&k=Software+jewelry&w1=Software+jewelry\
&w2=Software+deployment&w3=Service+software&w4=Software+for+non+profits&w5=Compu\
ter+monitoring+software&c=5&s=133&.sig=YnB_1OoaXO3PjXXs-PW1ug>  Software
>
deployment<http://groups.yahoo.com/gads?t=ms&k=Software+deployment&w1=Software+j\
ewelry&w2=Software+deployment&w3=Service+software&w4=Software+for+non+profits&w5\
=Computer+monitoring+software&c=5&s=133&.sig=wgkmKVaiIGQ-sl9iYNyjzg>  Service
>
software<http://groups.yahoo.com/gads?t=ms&k=Service+software&w1=Software+jewelr\
y&w2=Software+deployment&w3=Service+software&w4=Software+for+non+profits&w5=Comp\
uter+monitoring+software&c=5&s=133&.sig=OyF0MXXtwMiT3x3pcJ6Rpw>   Software
> for non
profits<http://groups.yahoo.com/gads?t=ms&k=Software+for+non+profits&w1=Software\
+jewelry&w2=Software+deployment&w3=Service+software&w4=Software+for+non+profits&\
w5=Computer+monitoring+software&c=5&s=133&.sig=KN-Sgt0lEpBXnoGP_On2rw>  Computer
> monitoring
software<http://groups.yahoo.com/gads?t=ms&k=Computer+monitoring+software&w1=Sof\
tware+jewelry&w2=Software+deployment&w3=Service+software&w4=Software+for+non+pro\
fits&w5=Computer+monitoring+software&c=5&s=133&.sig=QyEL_KTrUrONhd2MEms5FQ>
>  ------------------------------
> YAHOO! GROUPS LINKS
>
>
>    - Visit your group "extremeperl<http://groups.yahoo.com/group/extremeperl>"
>    on the web.
>     - To unsubscribe from this group, send an email to:
>   
extremeperl-unsubscribe@yahoogroups.com<extremeperl-unsubscribe@yahoogroups.com?\
subject=Unsubscribe>
>     - Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>    Service <http://docs.yahoo.com/info/terms/>.
>
>
>  ------------------------------
>


[Non-text portions of this message have been removed]

Adam Sroka writes:
> I never declare the number of units. A "best practice" to someone is a
> silly, waste of time to someone else. However, instead of writing my own
> test framework:

We have about 12,000 lines of unit tests.  We have 1,500 lines
(including lengthy pod) of test framework.  I would estimate that
we have 50% fewer lines of unit test code than if we had used an
imperative framework.  That's a total savings of about 4,000 lines.
More importantly, when I look at a test, I see what it is testing.

> use Test::More qw(no_plan);

This actually is a very important part of the framework.  You need to
know what you are measuring before you know whether your test works or
not.

> Since we don't HAVE to do that, the question becomes, why would we
> want to? I wouldn't. You'll have to explain why you would.

The simplest explanation is that I know where to find things.  One of
the bad things about Perl is namespace pollution.  We maintain a large
number of complex applications.  One day I'm working on a new
advertising venture and the next I'm working on a tax collection
package for surplus lines insurance.  I can't be bothered to remember
anything about what I have written a couple of months ago, let alone
several years ago.  We always qualify our code references with the
name of the package so that we can find the object instantly.  We only
use single inheritance for the same reason.

The other reason is that classes are an excellent mechanism for
reuse, esp. in Perl where they are truly first-class.  We use other
mechanisms, such as closures, for other forms of sharing, but when it
comes to managing a large collection of code, classes are simple and
effective.

> I wouldn't because I think that the nature of testing is procedural,

If you write procedural code, the nature of testing is procedure.  The
problem with procedural code is that it is stateful.  The most
difficult problems to debug are caused by impliciting coupling of
shared state.  If you look at the latest bOP release, you'll notice
that I fixed several defects by changing implicit to explicit
coupling.

The way you couple your code is important.  Back to the test example
from my book (http://www.extremeperl.org/bk/test-driven-design):

      use strict;
      use Test::More tests => 9;
      use Test::Exception;
      BEGIN {
	  use_ok('EMA');
      }
      ok(my $ema = EMA->new(4));
      is($ema->compute(5), 5);
      is($ema->compute(5), 5);
      is($ema->compute(10), 7);

The use of $ema is implicit coupling.  My book uses procedural code,
because it is my weak attempt at "being popular" (see
paulgraham.com).  Here's how it is written in the version available in
bOP:

     use strict;
     use Bivio::Test;
     Bivio::Test->new('Bivio::Math::EMA')->unit([
	 4 => [
	     compute => [
		 5 => 5,
		 5 => 5,
		 10 => 7,
	     ],
	 ],
     ]);

Note the explicit relationship between the object created (with 4) and
the method (compute) called repeatedly on that object.   In both
versions, the code must be executed imperatively.  However, in the
declarative version, you are shown the relationship through the
explicit nesting of a perl data structure.  You can't call the wrong
method, becuse it is mentioned only once.  You can't use the wrong
object, because it is declared only once.  In the first version, it's
much easier to have a mistake like this.

> needs to be an object, then I make one. That is the essence of XP - do
> the simplest thing that could possibly work. Most unit tests in other
> languages feel like procedures wrapped in classes anyway (e.g. TestCase
> feels more like a collection of testThis() methods than a proper class.)

You are correct, which is exactly the problem.  When you find yourself
typing testThis, testThat, and testTheOtherThing, you are repeating
yourself.  The rule of three says you need to get rid of the word
"test", and there is probably a strong relationship between This,
That, and TheOtherThing.

> Your code is every bit as repetitive as the code you are replacing. The
> difference is that you've dropped in a layer of abstraction
> (unnecessarily, IMO) between your repetitive test code and the main
> package. Test code is repetitive because testing is repetitive. You can
> hide that, but you haven't changed it.

There are two reasons I see for using classes: sharing and naming.
When you name a concept, you abstract the meaning into a symbol.  That
symbol is a handle.  When we use the word "chmod", we know what it
means, even though, it is rather meaningless.  The name helps us
communicate quickly.  If instead I had to speak about the abstraction
(like an Ent) by telling a long story about its origin (as I'm doing
now ;-), it makes if very difficult to work together.   We continually
reestablishing context, because we don't have a common vocabulary.

It's why programming languages with positional parameters dominate the
programming space.  The shorter the name for common tasks (such as
testing), the less the name interferes with the task itself.  It's why
drag-and-drop interfaces are popular, you don't need to remember the
command name to invoke an operation.  You simply do it.  It's not
always intuitive, but it's easy to learn.  It's much harder to learn:

     mv foo bar

than it is to "double click" on "foo" and type "bar".

The other reason I use classes is for sharing, which to me means,
fewer defects.  Less is more.  That's what OAOO means to me, anyway,
and that's why we have our own unit test infrastructure.

Rob

Rob Kinyon writes:
> That is a personal preference. I prefer mocks, because it allows me to
> test in isolation. My theory is that perfect components will work
> together perfectly. It also forces me to work out my APIs a lot
> sooner. This means that I can refactor with confidence.

Testing does not make perfect.  Code proofs don't even make perfect.
The definition of perfect is constantly changing.

Working out APIs a lot sooner is great, but I prefer reality for this.
I just ripped up a bunch of code, because reality was never what I
thought it was, and it changed anyway to a thing called CSS.

> Unfortunately, that doesn't work out in real life. I have only to
> point to the Riemann Hypothesis. (There is no X^n + Y^n = Z^n, X, Y,
> Z, and n being integers where n > 2.) The proof took 400 years, 300M
> IQ points, and about 200 pages to accomplish.

I wonder if anybody's refactored the proof to shorter than 200
pages. :-)  Refactoring is hard, and it takes a lot of IQ points, and,
unfortunately, tightly refactored code (or proofs) requires a high IQ
to understand.

> Absolutely. And, I do refactor my tests. However, I focus primarily on
> refactoring my code so that I need fewer tests overall. If I can test
> the same functionality with fewer tests by using cleaner APIs and mock
> objects, isn't that also good?

My experience tends to be different.  I often add tests before I
refactor.  I am refactoring, because the code is useful and in use,
often in ways I never anticipated.  The extra tests help me refactor,
because they encode the assumptions I hadn't thought of when I wrote
the code originally.

Rob

On Mon, 2005-08-29 at 16:23 -0600, Rob Nagler wrote:

> The shorter the tests, the fewer the number of bugs.

I think you mean "the simpler the tests, the probably fewer the number
of bugs".  Otherwise, I completely disagree; your code has to get
specific *somewhere*.

-- c

Rob Nagler wrote:

> We have about 12,000 lines of unit tests. We have 1,500 lines
>
>(including lengthy pod) of test framework.  I would estimate that
>we have 50% fewer lines of unit test code than if we had used an
>imperative framework.  That's a total savings of about 4,000 lines.
>More importantly, when I look at a test, I see what it is testing.
>
>
I can't recall the last time I opened a test and didn't know what it was
testing, but if this ever happened I suppose my response would go
something like this: I would go to the thing under test and start
deleting parts of it until something broke. Hopefully, by then I would
have figured out what the test was doing and been able to refactor it.
All the while, I would complain loudly, and, usually, the person who
wrote the code would come to their own defense providing an explanation
of why they wrote what they wrote. When they don't it's usually because
it was me.

>>use Test::More qw(no_plan);
>>
>>
>
>This actually is a very important part of the framework.  You need to
>know what you are measuring before you know whether your test works or
>not.
>
>
I am doing TDD, I know what I am testing. I am testing the thing that
doesn't exist now, but will when the test passes. I don't need to have a
number that I change every time I run the test. If I added a test then I
have one more than I did last time I ran the test. Otherwise I have the
same number. Test::Harness (via prove) will tell me the exact number.

>If you write procedural code, the nature of testing is procedure.  The
>problem with procedural code is that it is stateful.  The most
>difficult problems to debug are caused by impliciting coupling of
>shared state.  If you look at the latest bOP release, you'll notice
>that I fixed several defects by changing implicit to explicit
>coupling.
>
>The way you couple your code is important.  Back to the test example
>from my book (http://www.extremeperl.org/bk/test-driven-design):
>
>     use strict;
>     use Test::More tests => 9;
>     use Test::Exception;
>     BEGIN {
>  use_ok('EMA');
>     }
>     ok(my $ema = EMA->new(4));
>     is($ema->compute(5), 5);
>     is($ema->compute(5), 5);
>     is($ema->compute(10), 7);
>
>The use of $ema is implicit coupling.  My book uses procedural code,
>because it is my weak attempt at "being popular" (see
>paulgraham.com).  Here's how it is written in the version available in
>bOP:
>
>    use strict;
>    use Bivio::Test;
>    Bivio::Test->new('Bivio::Math::EMA')->unit([
> 4 => [
>     compute => [
>  5 => 5,
>  5 => 5,
>  10 => 7,
>     ],
> ],
>    ]);
>
>Note the explicit relationship between the object created (with 4) and
>the method (compute) called repeatedly on that object.   In both
>versions, the code must be executed imperatively.  However, in the
>declarative version, you are shown the relationship through the
>explicit nesting of a perl data structure.  You can't call the wrong
>method, becuse it is mentioned only once.  You can't use the wrong
>object, because it is declared only once.  In the first version, it's
>much easier to have a mistake like this.
>
>
>
Hmm... three different tests, three different method calls. Makes sense
to me. Your approach is still performing three different tests, but you
are HIDING this fact in your implementation. IMHO, your approach is LESS
clear. As for the issue of state, if $ema has some state that is
maintained from one invocation to the next the test should make that
clear. The way the test is written does not call for any state,
therefore you shouldn't implement any. If you do, you are NOT doing TDD.

>>needs to be an object, then I make one. That is the essence of XP - do
>>the simplest thing that could possibly work. Most unit tests in other
>>languages feel like procedures wrapped in classes anyway (e.g. TestCase
>>feels more like a collection of testThis() methods than a proper class.)
>>
>>
>
>You are correct, which is exactly the problem.  When you find yourself
>typing testThis, testThat, and testTheOtherThing, you are repeating
>yourself.  The rule of three says you need to get rid of the word
>"test", and there is probably a strong relationship between This,
>That, and TheOtherThing.
>
>
>
I think you are taking the idea of duplication a little too far.
Duplication is okay when it conveys something useful. For example, if I
have three things to test I write three tests. It is clear to everyone
who reads my test code that it contains three tests. This is a good thing.

>>Your code is every bit as repetitive as the code you are replacing. The
>>difference is that you've dropped in a layer of abstraction
>>(unnecessarily, IMO) between your repetitive test code and the main
>>package. Test code is repetitive because testing is repetitive. You can
>>hide that, but you haven't changed it.
>>
>>
>
>There are two reasons I see for using classes: sharing and naming.
>
>
Since I am using Test::* packages from CPAN, I am fairly sure that the
framework is well shared. I am also pretty sure that other perl
programmers will understand the tests I have written. As for naming, I
keep my test files small, one per thing (Class, Package, Script, etc.)
under test. I also keep my fixtures in the smallest lexical scope
necessary.

I use classes a lot. I use them when I have data with particular
semantics and I don't want to worry about the details of its behavior
every time I use it. I just want to call it and have it do the right
thing. "Test" does not meet my criteria:

1) it doesn't encapsulate any data
2) if there is no data, then there is no behavior associated with that data
3) in fact, test is a behavior the result of which is true or false
(pass or fail). It takes data (The thing to test) and returns a result.
It is a function/method/procedure not a class. Forcing "Test" to be a
class is a kludge, IMO.

Adam Sroka <adam.s@...> writes:

> I just use Test::More and prove.

what is prove? I could not find it in the main Test::More docs:

http://search.cpan.org/~mschwern/Test-Simple-0.60/lib/Test/More.pm

--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

Check out this page on CPAN:

http://search.cpan.org/~petdance/Test-Harness-2.52/bin/prove
<http://search.cpan.org/~petdance/Test-Harness-2.52/bin/prove>

   _____

From: extremeperl@yahoogroups.com [mailto:extremeperl@yahoogroups.com] On
Behalf Of Terrence Brannon
Sent: Wednesday, August 31, 2005 7:10 AM
To: extremeperl@yahoogroups.com
Subject: Re: [extremeperl] unit tester


Adam Sroka <adam.s@...> writes:

> I just use Test::More and prove.

what is prove? I could not find it in the main Test::More docs:

http://search.cpan.org/~mschwern/Test-Simple-0.60/lib/Test/More.pm
<http://search.cpan.org/~mschwern/Test-Simple-0.60/lib/Test/More.pm>




[Non-text portions of this message have been removed]

All:

     Please forgive a noob for spamming you folks with HTML.  Terrence, here
is the link for "prove":
http://search.cpan.org/~petdance/Test-Harness-2.52/bin/prove

Regards,
Chris Hudgins

Rob Nagler wrote:

   >in Bivio::Test this would be:
   >
   >    use strict;
   >    use Bivio::Test;
   >    Bivio::Test->new('EMA')->unit([
   >      EMA => [
   >          new => [
   >            -2 => Bivio::DieCode->DIE,
   >            0 => Bivio::DieCode->DIE,
   >            1 => undef,
   >            2.5 => Bivio::DieCode->DIE,
   >          ],
   >      ],
   >    ]);

You know, I really think this is interesting when you compare it to
another email:

>  > #! /usr/bin/perl
>  >
>  > use strict;
>  > use warnings;
>  > use Our::Test::HTML::HouseStyle qw( style_ok );
>  > use Our::Test::Config qw( html_files );
>  > use Our::Test::Utils qw( test_all );
>  >
>  > test_all { style_ok( $_ ) } html_files();
>
>  Note the redundancies.  test_all x 2, style_ok x 2, and test_all x 2;
>  qw() is twice. 

Despite the complaints that Adrian Howard's code had a lot of
duplication, the Bivio code still had duplication in the call to
Bivio::DieCode->DIE.  but I'm still curious about the declarative
nature of the code.  I could see refactoring the Bivio to this:

  use Bivio::Test;
    Bivio::Test->new('EMA')->unit([
      # is the duplicate "EMA" necessary?
      EMA => [
        new => [
          [ -2, 0, 2.5 ] => Bivio::DieCode->DIE,
          1 => undef,
        ],
      ],
    ]);

Given that most are unlikely to use Bivio, perhaps someone can propose
a Test::Declare framework using Perl's standard testing tools?  What
would the syntax be?

Cheers,
Ovid