Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

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

on

  • 3,477 views

Introducing a new coding technique that helped PretaWeb deliver a large workflow system on time, on budget and most importantly, delivered what we expected to deliver. ...

Introducing a new coding technique that helped PretaWeb deliver a large workflow system on time, on budget and most importantly, delivered what we expected to deliver.

This will cover

• unit and doctest in python,
• test driven development,
• usecase analysis,
• automated functional web testing,
• some practical examples using Grok and
• a brief look at documentation driven development.
Techniques covered are applicable to small and large web developments

Statistics

Views

Total Views
3,477
Views on SlideShare
3,472
Embed Views
5

Actions

Likes
1
Downloads
21
Comments
0

1 Embed 5

http://www.slideshare.net 5

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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
    • 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 - 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: 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/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