TestBrowser Driven Development: How to get bulletproof code from lazy developers

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

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

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

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

CRC Card sessions
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

Paper Based Prototype
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

Unit Testing
Code
Write test
Run test: it succeeds
Refactor
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 - ✓

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

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

TestBrowser extras
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

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: 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: Branch merged

Test Driven Development
Write test
Run test: it fails
Fix code
Refactor
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

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

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 = $$$

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

TestBrowser Driven Development: How to get bulletproof code from lazy developers

by Dylan Jay on Sep 21, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 5

Statistics

TestBrowser Driven Development: How to get bulletproof code from lazy developers — Presentation Transcript