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]
[Non-text portions of this message have been removed]
