Practical Test-driven Development Presentation

Concepts of Test Driven Development

Concepts of Testing

•Think along the lines of “Lather, Rinse, Repeat” only it’s “Fail, Fix, Pass”.

•You write a test before you write any ‘real’ code and then don’t actually write code until the test fails.

•After the test fails, you minimally modify your code in order to make the test pass.

•Once you think that you’ve got your code ready to make the test pass, you verify that the test does indeed pass and then repeat the process.

•The entire time you are coding, you are looking for places where you can both refactor your code and refactor your tests.

•Failing tests before code!

11

Setting up our example

•Throughout the class, we’ll be creating a Perl module that will calculate percentage of ownership for an owner in a condo.

•The percentages are used for important things like association elections and assessments, so they have to be correct or lawyers will get involved.

12

Details of the calculation

Setting up our example

•The formula works by determining the percentage of the building that an individual owns in proportion to the total livable space. Common areas are not included.

•The trick is that the actual square footage of any unit is weighted using multiplier. Each floor up adds an extra hundredth to the weight. For instance, a 600 square foot unit on the 11th floor would be weighted at 600 * 1.11 = 666.

13

Details of the calculation

Setting up our example

•Don’t worry about units that span multiple floors.

•Ninety-nine floors are the most that any building can have.

•Don’t worry about matching up owners who have multiple units.

•Underground floors all get a weight of zero, no matter how many levels down they actually are.

14

Basic Testing in Perl

•Creating tests with Test::More

•Running tests with prove

•A deeper look at Test::More

•Taking a look at the TAP

•Taking a look back at Test::Simple

15

Creating tests with Test::More

Basic Testing in Perl

•We have a rough set of requirements.

•What do we do first?

•Create a technical design?

•Write out an object interface specification?

•Write some code?

16

Creating tests with Test::More

Basic Testing in Perl

"t/percent_ownership.t"

1 use warnings;

2 use strict;

3 use Test::More tests => 1;

4

5 BEGIN { use_ok('PercentOwnership'); }

17

Running tests with prove

Basic Testing in Perl

•So we have a nice test written that tries to load our yet-to-be-created module, PercentOwnership. Now what do we do?

•Since the test is just a Perl script, we could run it using the ‘perl’ executable on our system.

•‘perl’ alone isn’t the best candidate for the job though.

•When you installed Perl, it not only installed ‘perl’ and ‘perldoc’, but it also installed a handy program for running your tests, ‘prove’.

18

Running tests with prove

Basic Testing in Perl

--(0)> prove t/percent_ownership.t

t/percent_ownership....

#Failed test 'use PercentOwnership;'

#at t/percent_ownership.t line 5.

#Tried to use 'PercentOwnership'.

#Error: Can't locate PercentOwnership.pm in @INC (@INC contains: ...) at (eval 3) line 2.

# BEGIN failed--compilation aborted at t/percent_ownership.t line 5.

# Looks like you failed 1 test of 1.
t/percent_ownership	....dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test	Stat Wstat Total Fail Failed List of Failed

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

t/percent_ownership.t	1	256	1	1 100.00% 1
Failed 1/1 test scripts,	0.00% okay.		1/1 subtests failed, 0.00% okay.

19

Running tests with prove

Basic Testing in Perl

•Now that we’ve created a test and the test fails, it’s time to write some ‘real’ code so that our test can pass.

•It is a common test driven development practice to write a test, watch it fail, and then fix the code that you are testing by doing only the minimal amount of work necessary to make the test work.

•The word minimal is stressed because that is one of the most difficult aspects of test driven development.

•It is very tempting to add a feature that you ‘know’ will be needed while you are in the code working to make a test pass. Don’t!

•No code should be written until a test is written to verify that code.

20