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