FIT and JBehave - Good, Bad and Ugly
•Descargar como PPTX, PDF•
2 recomendaciones•2,557 vistas
A 6 minute lightning talk at Sep 2, 2010 Practical Agility session in Minneapolis MN (DevJam). Notes available in the PPTX.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Más de Brian Repko
Último
Último (20)
FIT and JBehave - Good, Bad and Ugly
- 1. FIT and JBehaveThe Good, the Bad and the Ugly Practical Agility Lightning Talk Sep 2, 2010
- 3. FIT FITLibrary / SLIM Fitnesse
- 4. HTML Tables In HTML Tables Out
- 5. Fixtures
- 6. Wiki
- 7. Ease of Use
- 8. Existing Features (Selenium, DBFit)
- 14. Difficult to do Test First
- 15. JBehave
- 16. Plain-Text Story Given/When/Then (Story and Scenarios)
- 17. Steps Classes with Annotations / Regex
- 18. Story Class (optional) as bridge from Story (text) to Steps
- 19. Flow for Agile (Test First) (Defines Done)
- 22. No Tags for You!
- 23. Reporting
- 24. ! (JUnit | TestNG)
- 25. What features would the ideal ATDD framework have?
Notas del editor
- Both are ATDDBoth are pure JavaThey are the only 2 that I’ve worked with on projects
- FIT is the core library – HTML tables as data – parsing the table calls into a Fixture object’s methodsFITlibrary / SLIM – libraries for fixture developmentFitness – a test management and execution tool
- FIT input is HTML tables and output is HTML tables (styled)
- Table/Row/Column maps to method in fixture class
- Fitnesse is a wiki – allows for add/edit/delete/run as well as meta/text for tests
- Easy to use – has been around for a while
- Easy to drive a web UI with SeleniumFixtureEasy to populate or verify database state with DBFit
- Partitioning your tests in Fitnesse by “state” is toughTag/Branch test w/ code is tough with FitnesseFitnesse creates zip files for versioning
- Want to code test based on functionality and not UIDB is pre/post conditionToo brittle for refactoring – want to use the fixtures in my own fixtures
- Hard to think in “tables” (particularly when they are parsed differently)
- Model is not Table, Row and Column which are all ParseableAll are modeled as a ParseParse is a verb not a noun – really hard to read the APISurprisingly, the FIT code was listed in one book as a “superbly designed API”In the end – its hard to write fixtures
- Spend lots of time on the “design of the fixture” rather than the actual tests
- JBehave 3 in particular
- Story text is plain-text (UTF-8) with i18n’d keywordsScenarios are Given/When/Then format
- Steps classes are POJOs with annotated @Given(regex), @When(regex), @Then(regex) methodsRegex is matched against text in the storySteps classes are like a library of fixtures
- Story class can map the Story text to the set of Steps classes needed for itCan also be used to say when a story is “included in the execution suite”
- Tests don’t run until Story class exists (one way to run)Scenarios are used to define done – and can actually be written early
- JBehave can load the story text from anywhere – any source that BA/QA folks use (and can be versionable)
- Some strange use of fluent language and builder patternsStrange API around Embedder and Embeddable
- No tags per story / scenario (yet)Useful for conditional execution
- Have to do this by hand – built-in reporting types require custom code (see examples)
- A story (with all its scenarios) is one test methodCan’t run just one scenarioNo ability to monitor like JUnit/TestNG does for test classes/methods