Anatomy of a BDD Execution Library in Clojure

Anatomy of a BDD Execution Library in Clojure

I gave this talk at the Clojure Paris User Group about the inner details of a BDD library I wrote called Spexec.

6c7fb4b051926511027cec4116cfe8cf?s=128

Jérémie Grodziski

July 21, 2015
Tweet

Transcript

  1. Clojure! Anatomy of a BDD Execution Library! ! Clojure Paris

    User Group – July 2015!
  2. None
  3. What does a BDD lib need to do? Get Scenarios

    •  in Gherkin format (almost…) •  in text files, string, etc. Get Steps •  as regex + code •  will be executed against each steps of scenarios if regex match •  categorized with given/when/then Execute Scenarios Against Steps Provide Execution Report
  4. What is Gherkin? •  A format specifying how BDD-like scenarios

    should be written
  5. 1. Parser should transform scenarios as text in a data

    structure
  6. Instaparse for parsing Gherkin

  7. My experience with Instaparse •  Very easy to build and

    test a Grammar, even complicated one •  Beware of embedding too much regular expressions because of their greediness •  Large file or complex grammar: beware of performance and maintenability penalty with one grammar to parse the whole, better with modular/ separated parser
  8. 2. Get Steps •  A step is a keyword (given/when/then)

    with a regex and a function (macro provided as convenience, plain-old function provided as well)
  9. Steps handling •  Steps are stored in an atom for

    user convenience as well as the « before » and « after » functions •  Regex can’t be stored as map key because regex are stateful in Java L, so the string regex is used as a key and the function is the value
  10. Functional view of steps •  Traditional BDD framework in Java

    use one object with a state somewhere during scenarios execution •  Scenarios and scenario’s steps are a functional path through the domain and so THEY ARE DEPENDANT (contrary to unit testing) and are chained amongst themselves •  I prefer to think about steps as a chain where the return of a previous step is provided as an argument to the next one, and so on…
  11. 3a. Execute the whole Spec •  Nothing fancy here, just

    cumbersome details for getting the scenario as a data structure and then feeding the steps •  The specification execution is view as a function that return the execution report
  12. 3b. Get the Execution Report •  A Plain-Old Clojure Data

    Structure
  13. Why did I build that? What’s next? •  Because I

    can! J •  Full idiomatic Clojure Implementation •  I wanted better REPL integration and functional point of view •  Include Rules handling and execution as an enhancement to BDD •  Alternative in Clojure: cucumber-jvm, speclj (internal DSL)
  14. Want to try? Or contribute? •  https://github.com/zenmodeler/spexec •  Ideas: – 

    Execute step as standalone function, –  Mix Gherkin and Clojure code for « domain sketching » –  ?