TestBrowser Driven Development How to get bulletproof code from lazy developers Dylan Jay [email_address]

Dylan Jay 6 years with Plone Large corporate Java/Rational Unified process background Co-founder of PretaWeb in Australia Started pretaweb.funnelweb, collective.hostout, Products.LoginLockout (and way way back RemoteUserFolder) About me

Dylan Jay

6 years with Plone

Large corporate Java/Rational Unified process background

Co-founder of PretaWeb in Australia

Started pretaweb.funnelweb, collective.hostout, Products.LoginLockout (and way way back RemoteUserFolder)

What this talk is about Story of how we delivered the difficult (previous failures) Communication Users ↔ Business Analyst Business Analyst ↔ Developers For project managers, business analysts, technical leads But also for solo development

Story of how we delivered the difficult (previous failures)

Communication

Users ↔ Business Analyst

Business Analyst ↔ Developers

For project managers, business analysts, technical leads

But also for solo development

The story begins... Gov. department Complex Workflow Application of sensitive info – generating certificates BA 40% Dev 60% + support Fixed price + fixed deadline. Sold them on scrum … without mentioning scrum Used hybrid SCUM + usecase analysis

Gov. department

Complex Workflow Application of sensitive info – generating certificates

BA 40% Dev 60% + support

Fixed price + fixed deadline.

Sold them on scrum … without mentioning scrum

Used hybrid SCUM + usecase analysis

Roles: reference BA: Business Analyst - Extract requirements from client and produce requirements document. Traditionally job ends before code begins PO: Product Owner - In SCRUM: Sort of like a BA who sticks around. Go to person. Dev: Developer - People who want solve code problems not user problems :) ST/QA: System Tester - Non-developers there to break developers work

BA: Business Analyst - Extract requirements from client and produce requirements document. Traditionally job ends before code begins

PO: Product Owner - In SCRUM: Sort of like a BA who sticks around. Go to person.

Dev: Developer - People who want solve code problems not user problems :)

ST/QA: System Tester - Non-developers there to break developers work

CRC Card sessions Class, Responsibility, Collaboration

Class, Responsibility, Collaboration

Use-case analysis Great for workflow/edge cases Usecase: 1 main scenario (sunny day) ~30 alternate scenarions (rainy day) Challenge - level of detail Premature detail vs. not enough ~50 scenarios 43 page word doc including non-functional requirements

Usecase:

1 main scenario (sunny day)

~30 alternate scenarions (rainy day)

Challenge - level of detail

Premature detail vs. not enough

~50 scenarios

43 page word doc including non-functional requirements

Paper Based Prototype http://www.balsamiq.com/products/mockups

http://www.balsamiq.com/products/mockups

Stories vs Usecases We used SCRUM SCRUM uses Stories Stories are good for estimation Stories group functionality vs. Scenarios runs across functionality We Broke large scenario into three stories Grouped 3-4 related scenarios into stories

We used SCRUM

SCRUM uses Stories

Stories are good for estimation

Stories group functionality vs. Scenarios runs across functionality

We

Broke large scenario into three stories

Grouped 3-4 related scenarios into stories

Unit Testing Code Write test Run test: it succeeds Refactor Run test: it succeeds Tests are code Test functions/API Tests run fast Tests run often Tests run after every change

Code

Write test

Run test: it succeeds

Refactor

Run test: it succeeds

Tests are code

Test functions/API

Tests run fast

Tests run often

Tests run after every change

Unit Testing – scorecard Communication of requirements - x Validation of requirements – x Prevent regressions - ✓

Communication of requirements - x

Validation of requirements – x

Prevent regressions - ✓

Doctests Structured text document Tells a story Tells a story with EXAMPLES THAT WORK! Code interleaved Output checked against actual == test docstring or standalone doctests

Structured text document

Tells a story

Tells a story with EXAMPLES THAT WORK!

Code interleaved

Output checked against actual == test

docstring or standalone doctests

Functional Testing Test system from outside – GUI after development Written from user perspective Easy to write – write it as you would use it Usecase = test Often done by separate team – system testers Often done just before delivery Example: selenium

Test system from outside – GUI after development

Written from user perspective

Easy to write – write it as you would use it

Usecase = test

Often done by separate team – system testers

Often done just before delivery

Example: selenium

Selenium

zc.testbrowser an api browser Easy to keep in your head – fun - natural browser.getControl( label=None, name=None, index=None ) /.options /.value /.click() browser.getLink( text=None, url=None, id=None ) /.click() browser.open(url) brower.goBack() browser.reload() print browser.contents

Usecases to tests Dev: Branch created Dev: Scenarios copied to StoryX.txt Dev: Code developed Dev: StoryX.txt augmented with testbrowser Dev: All Tests pass PO: Code + test reviewed PO: Branch merged

Dev: Branch created

Dev: Scenarios copied to StoryX.txt

Dev: Code developed

Dev: StoryX.txt augmented with testbrowser

Dev: All Tests pass

PO: Code + test reviewed

PO: Branch merged

TestBrowser extras Doesn't do javascript But zc.testbrowser.real does Requires firefox Zope.testrecorder Generate tests from GUI With Plone use roadrunner

Doesn't do javascript

But zc.testbrowser.real does

Requires firefox

Zope.testrecorder

Generate tests from GUI

With Plone use roadrunner

Still not working... Implemented wrong thing – rework Usecases not detailed enough Lazy BA – didn't want tell developers how to do it Lazy developers – didn't want at the user level

Implemented wrong thing – rework

Usecases not detailed enough

Lazy BA – didn't want tell developers how to do it

Lazy developers – didn't want at the user level

Functional Test Driven Development PO: Branch created PO: Scenarios copied to StoryX.txt PO: StoryX.txt augmented with tests (sort of) Dev: Code developed Dev: Test finished off Dev: All tests pass PO: Code + test reviewed PO: Branch merged

PO: Branch created

PO: Scenarios copied to StoryX.txt

PO: StoryX.txt augmented with tests (sort of)

Dev: Code developed

Dev: Test finished off

Dev: All tests pass

PO: Code + test reviewed

PO: Branch merged

Our process – Bugs Dev: Branch created Dev: StoryX.txt add in bug condition Dev: Show test fails Dev: Code fixed Dev: All tests pass PO: Code + test reviewed PO: Branch merged

Dev: Branch created

Dev: StoryX.txt add in bug condition

Dev: Show test fails

Dev: Code fixed

Dev: All tests pass

PO: Code + test reviewed

PO: Branch merged

Test Driven Development Write test Run test: it fails Fix code Run test: it succeeds Refactor Run test: it succeeds Repeat Write tests before code red/green/refactor First fail then fix Forces you to understand requirements before writing code

Write test

Run test: it fails

Fix code

Run test: it succeeds

Refactor

Run test: it succeeds

Repeat

Write tests before code

red/green/refactor

First fail then fix

Forces you to understand requirements before writing code

TestBrowser Driven Development Communication of requirements - ✓ Level of detail right Easy – ✓ Technical PO can do it in reasonable time Validation of requirements – ✓ Easy to see changes to tests Prevent regressions - ✓ Test suite run after any change e.g. 1862 bug

Communication of requirements - ✓

Level of detail right

Easy – ✓

Technical PO can do it in reasonable time

Validation of requirements – ✓

Easy to see changes to tests

Prevent regressions - ✓

Test suite run after any change e.g. 1862 bug

Example: URL Shortener

Proposal: Screenshot gen Testbrowser statements -> screenshot Highlight action or comparison in screenshot Doctests with pictures and no code A better pypi & Plone Software Center Documentation Driven Development

Testbrowser statements -> screenshot

Highlight action or comparison in screenshot

Doctests with pictures and no code

A better pypi & Plone Software Center

Documentation Driven Development

Conclusion ~50 usecases all turned into doctests and extended Living requirements/documention Quality was very important delivered with peace of mind Tight deadline, tight budget delivered on time on budget Lazy developers less rework, less delays = $$$

~50 usecases

all turned into doctests and extended

Living requirements/documention

Quality was very important

delivered with peace of mind

Tight deadline, tight budget

delivered on time on budget

Lazy developers

less rework, less delays = $$$

Credits http://docs.python.org/library/doctest.html http://pypi.python.org/pypi/zc.testbrowser http://plone.org/documentation/tutorial/testing/functional-tests