[Saltlake-pm] TDD workshop follow-up

David Oswald daoswald at gmail.com
Wed Jul 10 10:45:54 PDT 2013


If anyone is interested in sharing how their TDD mini-project turned
out, feel free to post for us to see.  I did mine in a similar
workshop about 9 months ago at Thousand Oaks Perl Mongers.  Here is
how I chose to test and implement the project:

https://gist.github.com/daoswald/3876537

My implementation initializes a game object.  Then a qw( list of moves
) is supplied, and finally, a call to "winner" will return who won (if
anyone).  I treated the board as a string of [xo-], and each move is
checked to see if it produces a winner.  After a given move is placed,
the board string is matched against a regular expression to detect
winning patterns.  No winner, place the next move and match again.
Eventually either we find a winning board or no more moves and no
winner.

The regexp match strategy probably wouldn't help to dispel the myth
that Perl is read-only.  Treating the board as a matrix is probably a
much more obvious solution.  But 9 months ago I had been playing a lot
with defining sub-patterns in extended regexes, and it seemed like a
fun opportunity to use them.

The tests start by testing if the module can be loaded, if the
constructor can be called, if the constructor returns a reference to
an object of type TicTac, and so on.  Test coverage is 100%.

Really the point to the exercise is to constrain ourselves to thinking
in terms of the TDD steps: "Test, Code, Refactor, Repeat".  Writing a
test, and then the code to make it pass forces us to think of the
implementation and the interface before we start writing code.  Though
refactoring is a part of TDD, it tends to be limited to smaller units
of functionality, rather than getting two days into a project and then
deciding that we're in a corner surrounded by wet paint.

My hope is that even if we don't all start our next day's work by
writing tests, we at least find ourselves integrating tests more
closely into our development process, ultimately spending a little
more time writing tests, and a lot less time picking bugs out of
spaghetti. ;)

I mentioned a good book: Perl Testing, a Developer's Notebook, by Ian
Langworth and chromatic (OReilly).  Another book worth looking at is
Intermediate Perl (OReilly), as it devotes some of its pages to
testing as well.

Other lesser known Perl books that deal with testing: The Definitive
Guide to Catalyst (Apress), and Writing Perl Modules for CPAN
(Apress).


Dave

--

David Oswald
daoswald at gmail.com


More information about the Saltlake-pm mailing list