Requirements he wants to address

• Use case centered
• Hight level
• Readable
• Reusable
• Extensibility
• Modularization

Acceptance Testing for Plone with Funittest

• Write test first
• Guarantie the quality of your Plone sites
• Run in-browser acceptance tests: Selenium Remote Control (or Real TestBrowser).
• Extensive library of reusable scripts, verbs, scenario, and tests

Development with Funittest

• Documentation driven development
• Start with the Use Cases
• Write new use case scenarios or extensions
• Write high-level, domain specific, vocabulary for each new user action
• Functional tests reusing the scenarios

Presets

• Prepare a site for tests. Define users, etc…
• Custom presets

Data Providers (Test fixtures)

• Collection of example data for the tests (an example exists for a standard Plone site)
• Simple dictionary of dictionaries

Tests

• Manual tests are acceptable. What’s important is to test !
• Tests depend on the whole functional stack. You are testing that whole stack.

Verification steps

• Catch state before
• Change expected state
• Execute verb
• Compare expected state and real state

Other details about writing tests

• Verbs
• Scenarios, scenarios steps
• Extension Points. Extend scenarios.
• Scenarios can be used from Python code (interactively, can be useful to try scenarios/steps when coding)
• Physical Model: The low-level part. The way you attack Selenium Remote Control.

If interested

• Funittest is in the Collective
• There is sprint planned at the end of the conference
• Article on the subject by Andrea Jennitta: Brushing Up On Functional Test Effectivenes.
• Book by Alistair Cockburn: Writing Effective Use Cases.

At one of the Plone conference’s sessions this afternoon, I talked about using “Coaching” as a way to help companies for their Plone developments. I presented the case of HEP-Bejune where I worked with a team using that model, and the lessons learned from it.

For those who could not attend, you can get the PDF file of the presentation here.