FIT and JBehave - Good, Bad and Ugly


Published on

A 6 minute lightning talk at Sep 2, 2010 Practical Agility session in Minneapolis MN (DevJam).

Notes available in the PPTX.

Published in: Technology
1 Like
  • @Armen - reporting was greatly enhanced after the presentation. I worked through this with Mauro. The issues used to be that getting access to the FTL files was near impossible back in the day. This has all been worked out now.
    Are you sure you want to  Yes  No
    Your message goes here
  • whats wrong with reporting in JBehave? Also, I run tests using JUnitRunner...
    Are you sure you want to  Yes  No
    Your message goes here
  • @mike-at-gd - yes, those were added after this presentation - I'm actually a big fan of (and contributor to) JBehave so part of my criticisms were for things that I knew it needed
    Are you sure you want to  Yes  No
    Your message goes here
  • #22 is not absolutely right here is the tags
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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
  • FIT and JBehave - Good, Bad and Ugly

    1. 1. FIT and JBehaveThe Good, the Bad and the Ugly<br />Practical Agility<br />Lightning Talk<br />Sep 2, 2010<br />
    2. 2. Why These Two?<br />
    3. 3. FIT<br />FITLibrary / SLIM<br />Fitnesse<br />
    4. 4. HTML Tables In<br />HTML Tables Out<br />
    5. 5. Fixtures<br />
    6. 6. Wiki<br />
    7. 7. Ease of Use<br />
    8. 8. Existing Features<br />(Selenium, DBFit)<br />
    9. 9. Versioning<br />Partitioning<br />
    10. 10. Low-Level Fixtures<br />
    11. 11. Stakeholder Readability<br />
    12. 12. MethodNamesThatGoOnForeverOrUntilThePropsEnd<br />
    13. 13. The “Parse” Problem<br />
    14. 14. Difficult to do Test First<br />
    15. 15. JBehave<br />
    16. 16. Plain-Text Story<br />Given/When/Then<br />(Story and Scenarios)<br />
    17. 17. Steps Classes with<br />Annotations / Regex<br />
    18. 18. Story Class (optional)<br />as bridge from<br />Story (text) to Steps<br />
    19. 19. Flow for Agile<br />(Test First)<br />(Defines Done)<br />
    20. 20. Text From Anywhere<br />
    21. 21. Configuration API<br />Oddities<br />
    22. 22. No Tags for You!<br />
    23. 23. Reporting<br />
    24. 24. ! (JUnit | TestNG)<br />
    25. 25. What features would <br />the ideal ATDD framework have?<br />