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.

Transcript

1. Clojure! Anatomy of a BDD Execution Library! ! Clojure Paris User Group – July 2015!
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 » –  ?