开云体育

There are a number of reasons you might feel inclined to make a "testable"
subclass. Most of the time there is actually a simpler way to do it. To
help I'd need to understand why you are doing it. Could you explain what
these "sugar methods" do?

On Fri, Aug 31, 2012 at 10:06 AM, pierre masci <piemas25@...> wrote:

**


Is it a good or bad idea to subclass the Vehicule class with the
Vehicule_ForTests class,
which would contain all the "sugar" methods that i use to test the

Vehicule

class ?

It seems good, to not add useless methods to the public API...
but one could say that i can obtain the same result by starting my "sugar
for tests" methods with "_T" for instance.
It still feels nice to have these functions in a separate place.

Could it be dangerous or uncomfortable, too ?

------------------------------------

Yahoo! Groups Links

I'm learning Perl and TDD.

I'm thinking both about methods that will "run a fairly similar part of
several test cases",
and about methods who will be tests by themself : they will contain
assertions.

As a simple example, the Bowling-Game kata :
the exercise consists in building a Bowling-Game class,
which will calculate the score of a player, based on the number of pins
knocked at each roll.

For many tests, i need to do :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

foreach my $pins_knocked ( @rolls ) {
$game->rolled($pins_knocked);
}
my $result = $game->score();

cmp_ok($result, '==', $expected_score, # Describe your test here );
}

I like to refactor this into :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

my $result = $game->played_with(@rolls)
->score();

cmp_ok($result, '==', $expected_score, # Describe your test here );
}

played_with() is the type of sugar function that i want to create.


The other case can can be illustrated with the the
calculates_correct_score_with() sugar function which would directly replace
the above code by :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

$game->calculates_correct_score_with(@rolls, $expected_score);
}

What do you think ?




On Fri, Aug 31, 2012 at 6:22 PM, Adam Sroka <adam.sroka@...> wrote:

There are a number of reasons you might feel inclined to make a "testable"
subclass. Most of the time there is actually a simpler way to do it. To
help I'd need to understand why you are doing it. Could you explain what
these "sugar methods" do?

On Fri, Aug 31, 2012 at 10:06 AM, pierre masci <piemas25@...>
wrote:

**


Is it a good or bad idea to subclass the Vehicule class with the
Vehicule_ForTests class,
which would contain all the "sugar" methods that i use to test the

Vehicule

class ?

It seems good, to not add useless methods to the public API...
but one could say that i can obtain the same result by starting my

"sugar

for tests" methods with "_T" for instance.
It still feels nice to have these functions in a separate place.

Could it be dangerous or uncomfortable, too ?

------------------------------------

Yahoo! Groups Links

P.S. the ONLY reason I would put played_with in a subclass of $game is if
it needed to know about private bits inside of $game. However, actually
hiding members in Perl 5 turns out to be nearly impossible. So, that can't
be why, right?

On Fri, Aug 31, 2012 at 10:47 AM, Adam Sroka <adam.sroka@...> wrote:

My perl is a tad rusty, but I would recommend you just keep the
played_with() sub in the test. The only difference is you'd have to call

it

differently:

played_with($game, @rolls);

Subclassing $game just so that the test convenience method looks like a
member seems silly. Especially since the implementation would be

identical

(The instance is the first argument to a method call the -> is syntactic
sugar in Perl 5.x)


On Fri, Aug 31, 2012 at 10:40 AM, pierre masci <piemas25@...>

wrote:

**


I'm learning Perl and TDD.

I'm thinking both about methods that will "run a fairly similar part of
several test cases",
and about methods who will be tests by themself : they will contain
assertions.

As a simple example, the Bowling-Game kata :
the exercise consists in building a Bowling-Game class,
which will calculate the score of a player, based on the number of pins
knocked at each roll.

For many tests, i need to do :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

foreach my $pins_knocked ( @rolls ) {
$game->rolled($pins_knocked);
}
my $result = $game->score();

cmp_ok($result, '==', $expected_score, # Describe your test here );
}

I like to refactor this into :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

my $result = $game->played_with(@rolls)
->score();

cmp_ok($result, '==', $expected_score, # Describe your test here );
}

played_with() is the type of sugar function that i want to create.

The other case can can be illustrated with the the
calculates_correct_score_with() sugar function which would directly
replace
the above code by :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

$game->calculates_correct_score_with(@rolls, $expected_score);
}

What do you think ?


On Fri, Aug 31, 2012 at 6:22 PM, Adam Sroka <adam.sroka@...>

wrote:

There are a number of reasons you might feel inclined to make a

"testable"

subclass. Most of the time there is actually a simpler way to do it.

To

help I'd need to understand why you are doing it. Could you explain

what

these "sugar methods" do?

On Fri, Aug 31, 2012 at 10:06 AM, pierre masci <piemas25@...>

wrote:

**

Is it a good or bad idea to subclass the Vehicule class with the
Vehicule_ForTests class,
which would contain all the "sugar" methods that i use to test the

Vehicule

class ?

It seems good, to not add useless methods to the public API...
but one could say that i can obtain the same result by starting my

"sugar

for tests" methods with "_T" for instance.
It still feels nice to have these functions in a separate place.

Could it be dangerous or uncomfortable, too ?

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links

You can subclass your tests. Nothing wrong with that. Check this out:



On Fri, Aug 31, 2012 at 10:54 AM, pierre masci <piemas25@...> wrote:

**


Nope, i don't want to know about bits inside of $game.

I'm just trying to avoid to have to copy-paste played_with() in each test
file.
Maybe i should just have a package in my unit-test folder, where i declare
such functions.

Thank you for you help :o)


On Fri, Aug 31, 2012 at 6:51 PM, Adam Sroka <adam.sroka@...> wrote:

P.S. the ONLY reason I would put played_with in a subclass of $game is

if

it needed to know about private bits inside of $game. However, actually
hiding members in Perl 5 turns out to be nearly impossible. So, that

can't

be why, right?

On Fri, Aug 31, 2012 at 10:47 AM, Adam Sroka <adam.sroka@...>

wrote:

My perl is a tad rusty, but I would recommend you just keep the
played_with() sub in the test. The only difference is you'd have to

call

it

differently:

played_with($game, @rolls);

Subclassing $game just so that the test convenience method looks like

a

member seems silly. Especially since the implementation would be

identical

(The instance is the first argument to a method call the -> is

syntactic

sugar in Perl 5.x)


On Fri, Aug 31, 2012 at 10:40 AM, pierre masci <piemas25@...>

wrote:

**

I'm learning Perl and TDD.

I'm thinking both about methods that will "run a fairly similar part

of

several test cases",
and about methods who will be tests by themself : they will contain
assertions.

As a simple example, the Bowling-Game kata :
the exercise consists in building a Bowling-Game class,
which will calculate the score of a player, based on the number of

pins

knocked at each roll.

For many tests, i need to do :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

foreach my $pins_knocked ( @rolls ) {
$game->rolled($pins_knocked);
}
my $result = $game->score();

cmp_ok($result, '==', $expected_score, # Describe your test here );
}

I like to refactor this into :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

my $result = $game->played_with(@rolls)
->score();

cmp_ok($result, '==', $expected_score, # Describe your test here );
}

played_with() is the type of sugar function that i want to create.

The other case can can be illustrated with the the
calculates_correct_score_with() sugar function which would directly
replace
the above code by :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

$game->calculates_correct_score_with(@rolls, $expected_score);
}

What do you think ?


On Fri, Aug 31, 2012 at 6:22 PM, Adam Sroka <adam.sroka@...>

wrote:

There are a number of reasons you might feel inclined to make a

"testable"

subclass. Most of the time there is actually a simpler way to do

it.

To

help I'd need to understand why you are doing it. Could you explain

what

these "sugar methods" do?

On Fri, Aug 31, 2012 at 10:06 AM, pierre masci <piemas25@...

wrote:

**

Is it a good or bad idea to subclass the Vehicule class with the
Vehicule_ForTests class,
which would contain all the "sugar" methods that i use to test

the

Vehicule

class ?

It seems good, to not add useless methods to the public API...
but one could say that i can obtain the same result by starting

my

"sugar

for tests" methods with "_T" for instance.
It still feels nice to have these functions in a separate place.

Could it be dangerous or uncomfortable, too ?

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

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



------------------------------------

Yahoo! Groups Links

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

------------------------------------

Yahoo! Groups Links

Or, a non-OO alternative would be to put played_with in a module of its own
and call it from each different test module. That might be simpler to
start, but you should still check out Test:Class, because it is closer to
what we do in other languages for TDD.

On Fri, Aug 31, 2012 at 10:57 AM, Adam Sroka <adam.sroka@...> wrote:

You can subclass your tests. Nothing wrong with that. Check this out:



On Fri, Aug 31, 2012 at 10:54 AM, pierre masci <piemas25@...>

wrote:

**


Nope, i don't want to know about bits inside of $game.

I'm just trying to avoid to have to copy-paste played_with() in each

test

file.
Maybe i should just have a package in my unit-test folder, where i

declare

such functions.

Thank you for you help :o)


On Fri, Aug 31, 2012 at 6:51 PM, Adam Sroka <adam.sroka@...>

wrote:

P.S. the ONLY reason I would put played_with in a subclass of $game is

if

it needed to know about private bits inside of $game. However,

actually

hiding members in Perl 5 turns out to be nearly impossible. So, that

can't

be why, right?

On Fri, Aug 31, 2012 at 10:47 AM, Adam Sroka <adam.sroka@...>

wrote:

My perl is a tad rusty, but I would recommend you just keep the
played_with() sub in the test. The only difference is you'd have to

call

it

differently:

played_with($game, @rolls);

Subclassing $game just so that the test convenience method looks

like

a

member seems silly. Especially since the implementation would be

identical

(The instance is the first argument to a method call the -> is

syntactic

sugar in Perl 5.x)


On Fri, Aug 31, 2012 at 10:40 AM, pierre masci <piemas25@...>

wrote:

**

I'm learning Perl and TDD.

I'm thinking both about methods that will "run a fairly similar

part

of

several test cases",
and about methods who will be tests by themself : they will contain
assertions.

As a simple example, the Bowling-Game kata :
the exercise consists in building a Bowling-Game class,
which will calculate the score of a player, based on the number of

pins

knocked at each roll.

For many tests, i need to do :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

foreach my $pins_knocked ( @rolls ) {
$game->rolled($pins_knocked);
}
my $result = $game->score();

cmp_ok($result, '==', $expected_score, # Describe your test here );
}

I like to refactor this into :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

my $result = $game->played_with(@rolls)
->score();

cmp_ok($result, '==', $expected_score, # Describe your test here );
}

played_with() is the type of sugar function that i want to create.

The other case can can be illustrated with the the
calculates_correct_score_with() sugar function which would directly
replace
the above code by :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

$game->calculates_correct_score_with(@rolls, $expected_score);
}

What do you think ?


On Fri, Aug 31, 2012 at 6:22 PM, Adam Sroka <adam.sroka@...>

wrote:

There are a number of reasons you might feel inclined to make a

"testable"

subclass. Most of the time there is actually a simpler way to do

it.

To

help I'd need to understand why you are doing it. Could you

explain

what

these "sugar methods" do?

On Fri, Aug 31, 2012 at 10:06 AM, pierre masci <

piemas25@...

wrote:

**

Is it a good or bad idea to subclass the Vehicule class with

the

Vehicule_ForTests class,
which would contain all the "sugar" methods that i use to test

the

Vehicule

class ?

It seems good, to not add useless methods to the public API...
but one could say that i can obtain the same result by starting

my

"sugar

for tests" methods with "_T" for instance.
It still feels nice to have these functions in a separate

place.

Could it be dangerous or uncomfortable, too ?

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links

Smart ! I thought that Test::Class was mostly used to inherits unit-tests
from a class into its subclasses. And overload some of them when
needed. But you're right, it could also enable to subclass tests. I will
give it a go. I sounds a bit overkill for most cases, though.

The "module of its own" containing played_with() is what i was also
saying: I just used the word "package" instead of "module".



On Fri, Aug 31, 2012 at 7:00 PM, Adam Sroka <adam.sroka@...> wrote:

Or, a non-OO alternative would be to put played_with in a module of its
own
and call it from each different test module. That might be simpler to
start, but you should still check out Test:Class, because it is closer to
what we do in other languages for TDD.

On Fri, Aug 31, 2012 at 10:57 AM, Adam Sroka <adam.sroka@...>
wrote:

You can subclass your tests. Nothing wrong with that. Check this out:



On Fri, Aug 31, 2012 at 10:54 AM, pierre masci <piemas25@...>

wrote:

**


Nope, i don't want to know about bits inside of $game.

I'm just trying to avoid to have to copy-paste played_with() in each

test

file.
Maybe i should just have a package in my unit-test folder, where i

declare

such functions.

Thank you for you help :o)


On Fri, Aug 31, 2012 at 6:51 PM, Adam Sroka <adam.sroka@...>

wrote:

P.S. the ONLY reason I would put played_with in a subclass of $game

is

if

it needed to know about private bits inside of $game. However,

actually

hiding members in Perl 5 turns out to be nearly impossible. So, that

can't

be why, right?

On Fri, Aug 31, 2012 at 10:47 AM, Adam Sroka <adam.sroka@...>

wrote:

My perl is a tad rusty, but I would recommend you just keep the
played_with() sub in the test. The only difference is you'd have to

call

it

differently:

played_with($game, @rolls);

Subclassing $game just so that the test convenience method looks

like

a

member seems silly. Especially since the implementation would be

identical

(The instance is the first argument to a method call the -> is

syntactic

sugar in Perl 5.x)


On Fri, Aug 31, 2012 at 10:40 AM, pierre masci <piemas25@...

wrote:

**

I'm learning Perl and TDD.

I'm thinking both about methods that will "run a fairly similar

part

of

several test cases",
and about methods who will be tests by themself : they will

contain

assertions.

As a simple example, the Bowling-Game kata :
the exercise consists in building a Bowling-Game class,
which will calculate the score of a player, based on the number of

pins

knocked at each roll.

For many tests, i need to do :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

foreach my $pins_knocked ( @rolls ) {
$game->rolled($pins_knocked);
}
my $result = $game->score();

cmp_ok($result, '==', $expected_score, # Describe your test here

);

}

I like to refactor this into :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

my $result = $game->played_with(@rolls)
->score();

cmp_ok($result, '==', $expected_score, # Describe your test here

);

}

played_with() is the type of sugar function that i want to create.

The other case can can be illustrated with the the
calculates_correct_score_with() sugar function which would

directly

replace
the above code by :

{
my @rolls = # Set up a test case here
my $expected_result = # Idem

$game->calculates_correct_score_with(@rolls, $expected_score);
}

What do you think ?


On Fri, Aug 31, 2012 at 6:22 PM, Adam Sroka <adam.sroka@...

wrote:

There are a number of reasons you might feel inclined to make a

"testable"

subclass. Most of the time there is actually a simpler way to do

it.

To

help I'd need to understand why you are doing it. Could you

explain

what

these "sugar methods" do?

On Fri, Aug 31, 2012 at 10:06 AM, pierre masci <

piemas25@...

wrote:

**

Is it a good or bad idea to subclass the Vehicule class with

the

Vehicule_ForTests class,
which would contain all the "sugar" methods that i use to test

the

Vehicule

class ?

It seems good, to not add useless methods to the public API...
but one could say that i can obtain the same result by

starting

my

"sugar

for tests" methods with "_T" for instance.
It still feels nice to have these functions in a separate

place.

Could it be dangerous or uncomfortable, too ?

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links