Scribd
Upload
16 views

TDD Pfcongrez09

Uploaded by

Harentsoa Mahery ANJARANOTOAVINA
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
16 views

TDD Pfcongrez09

Uploaded by

Harentsoa Mahery ANJARANOTOAVINA
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 34

Test-Driven Development

pfcongrez - Maarsen, the Netherlands


Derick Rethans - [email protected]
http://derickrethans.nl/talks.php
About Me

● Dutchman living in Norway


● eZ Systems A.S.
● eZ Components project lead
● PHP development
● mcrypt, input_filter, date/time support, unicode
● QA
Introduction

It's OK to write code that does not work


It's OK to write code that does not work
Introduction

About Testing
Web Application Testing
Testable Parts

Front-end
● Acceptance Tests and System Tests that run in the

browser
● Testing of Web Services with Unit Tests

● Compatibility Testing for Browser/OS/etc. combinations

● Performance Testing

● Security Testing

Back-end
● Functional Testing of business logic with Unit Tests

● Reusable Components, but they often come with their

own tests
Testing Methods

Unit Testing
Tests small parts of an application or library (units) for
correctly working code. Tools: PHPUnit, SimpleTest
System Testing
The testing of a whole integrated system against the
specified requirements. Tools: Selenium
Non-functional Testing
Testing for performance, load, stress, reliability, availability,
security. Tools: ab, siege, httperf, chorizo
Test-Driven Development
a feature without a test is not a feature
Test-Driven Development

It is not just a method of testing


software.
Test-Driven Development

It is a religion.

✡✝☪
Back In Time
Traditional Development Phases

Requirements Specification
Define what the software is supposed to do.
Design
Define how the software is supposed to be implemented.
Implementation
The implementation of the software itself.
Testing
The implemented software is tested.
Sometimes.
Tests are King

Tests drive the development


● Tests are written before the code

● There is no code without tests

Test Suites
● Contain tests that check whether the code does what it

is supposed to do
● Also cover things that should fail
Into the Future
Test-Driven Development Phases

Requirements Specification
Define what the software is supposed to do.
Design
Define how the software is supposed to be implemented.
Implementation ≡ Testing
The implemented software is tested.
The implementation of the software itself.
Test-Driven Development
eZ Components Development

Present the Idea


Write the Requirements Document
Design the Component
Implementation
● Write API stubs with parameter documentation and

descriptions
● Write test cases

● Initial implementation

● Initial implementation review

● Updating implementation according to review

● Implementation review

Pre-release Testing
Test-Driven Development
Addressing Defects

Write Test Case


Write a test case to test the correct behavior of the method,
and verify that the test case fails
Fix the Issue
Fix the implementation
Verify Fix with Test Case
Make sure that the test cases pass with the new
implementation
Check Other Test Cases
Verify that the fix for this defect did not break any other test
case
The Way of Testivus

● If you write code, write tests.


● Don’t get stuck on unit testing dogma.

● Embrace unit testing karma.

● Think of code and test as one.

● The test is more important than the unit.

● The best time to test is when the code is fresh.

● Tests not run waste away.

● An imperfect test today is better than a perfect test

someday.
● An ugly test is better than no test.

● Sometimes, the test justifies the means.

● Only fools use no tools.

● Good tests fail.

http://www.artima.com/weblogs/viewpost.jsp?thread=203994
PHP Unit
PHPUnit
Unit Testing Framework for PHP
PHPUnit
Code Coverage: No Code Without Test
PHPUnit
Code Coverage: No Code Without Test

Green: Covered code.


Red: Not covered code.
Grey: Unreachable code.
White: No code.
PHPUnit
Code Coverage: How important?

< 100% Coverage ≡ Not fully tested code


100% Coverage ≢ Fully tested code

How much coverage should you aim for?


● It doesn't matter, just write some tests.

● How much rice do I need to cook?

● 100%, and no less!

http://www.developertesting.com/archives/month200705/200
70504-000425.html
phpUnderControl
Continuous integration with CruiseControl
Un-testable Problems

● Testing singletons more than one time


● System/Operating System dependent tests
● Private methods
● Code that depends on the state of an external
resource
● Things that simply should never happen
Politics
resistance to change
Developers

Fear - more work to do


● Introduce TDD concepts gently
● Whenever a problem is found, make and retain a test
case for futher use
● Start using TDD for new projects
Managers

Ignorance - too much time spent on testing


● Out of date with modern processes
● Belief that testing slows the schedule (only if you follow
the ship-and-see process)
● You save time later, because you wouldn't have to re-
test or re-debug newly written additions or big fixes.
Case Studies
Case Studies

Microsoft Case Study


● TDD project has twice the code quality

● Writing tests requires 15% more time

IBM Case Study


● 40% fewer defects

● No impact on the team's productivity

John Deere / Ericsson Case Study


● TDD produces higher quality code

● Impact of 16% on the team's productivity


Case Studies
Developer Comments

● At first I didn't like that I need to write tests for my


code, but now after using it for more than 10 months
I can't program without it.
● Helps to come up with better APIs.
● It gives confidence that our software is working well at
all times. Even after making major changes and/or
changing software we are dependent on.
● Productivity increases - you might loose some when
you make the initial tests, but you'll get it back later.
The code covered by tests is 'insured' against future
changes.
● It works well for libraries, not so well for GUI
applications.
● Some things cannot be tested like server errors, unless
Questions

?
Resources

● http://homepage.mac.com/hey.you/lessons.html
● Testuvius: http://www.artima.com/weblogs/viewpost.jsp?
thread=203994

● PHP Unit: http://phpunit.de


● phpUnderControl: http://phpundercontrol.org
● Xdebug: http://xdebug.org
● These Slides: http://derickrethans.nl/talks.php

● PHP: http://www.php.net

You might also like