• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

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,370 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,370
Views on SlideShare
3,365
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