Centralize execution code
Opened this issue · 0 comments
Zearin commented
Summary
While using Microcuke to write a Python implementation of Cucumber, I learned that after I had matched Mircocuke and proceeded to code further, I became uncomfortable with the spread of execution code.
Currently
- Some of the code lives in
sequential_test_case_executor.js
(which contains top-level execution code) - Some of the code lives in
test_case.js
- Some of the code lives in
test_step.js
Issues
- The name
SequentialTestCaseExecutor
implies that there might be alternate executors of some type. (This is the case in Python. I’m currently using aSequentialTestCaseExecutor
, but plan on writing anAsyncTestCaseExecutor
in the future.)
Recommendation
TestCase
andTestStep
should simply store the data required for execution (but not implement it)TestCase
should storepickle
andtestSteps
TestStep
should storegherkinLocations
,matchedArgs
,bodyFunction, and
bodyLocation`
- Move all execution functions/methods into the
sequential_test_case_executor.js
module- Write loosely-couple functions or classes for execution of
TestCase
andTestStep
; this will keep all the related execution code in one place, but keep each execution-scope as a distinct piece of code
- Write loosely-couple functions or classes for execution of
Benefits
This will make it easier to create implementations from Microcuke, because:
- Keeping all execution code in one place makes it easier to see how execution happens
- It’s much simpler to create alternatives to
SequentialTestCaseExecutor
, because any executor simply has to deal with the data ofTestCase
andTestStep
; all behavior is provided by the executor itself - Microcuke only cares about gherkin Scenarios (
TestCase
objects)- But Microcuke is missing many of the things handled by a full cucumber implementation (like Features, Backgrounds, and so on). That’s fine, because Microcuke is supposed to be “micro”. But Mircocuke is also supposed to be useful for growing a full-fledged cucumber implementation. Adding in things like Features, Backgrounds, etc. is much harder when the execution behavior is spread across 3 classes in 3 modules.
- Decoupling the execution data from its behavior also simplifies testing
- The overall program flow is: (1) scan for
*.feature
files and glue; (2) createTest*
objects that simply contain only data; (3) pass the objects to an executor. - Put another way, the flow is even shorter: (1) filesystem to data (
Test*
objects); (2) data to executor.
- The overall program flow is: (1) scan for
If you are okay with this, @aslakhellesoy, I can start it and send a Pull Request.