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!
   

   View Slide

2. View Slide

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
   

   View Slide

4. What is Gherkin?
   •  A format specifying how BDD-like
   scenarios should be written
   

   View Slide

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

   View Slide

6. Instaparse for parsing Gherkin
   

   View Slide

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
   

   View Slide

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)
   

   View Slide

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
   

   View Slide

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…
    

    View Slide

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
    

    View Slide

12. 3b. Get the Execution Report
    •  A Plain-Old Clojure Data Structure
    

    View Slide

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)
    

    View Slide

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 »
    –  ?
    

    View Slide