testbrowser driven development: how to get bulletproof code from lazy developers
If you can't read please download the document
TRANSCRIPT
TestBrowser Driven Development
How to get bulletproof code from lazy developers
Dylan Jay
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 casesUsecase: 1 main scenario (sunny day)
~30 alternate scenarions (rainy day)
Challenge - level of detailPremature 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
WeBroke 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
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 - naturalbrowser.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 doesRequires firefox
Zope.testrecorderGenerate 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: 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
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/refactorFirst 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 budgetdelivered 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
PloneConf 2009Dylan Jay