Centralize execution code

[Zearin]

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 a SequentialTestCaseExecutor, but plan on writing an AsyncTestCaseExecutor in the future.)

Recommendation

• TestCase and TestStep should simply store the data required for execution (but not implement it)
  • TestCase should store pickle and testSteps
  • TestStep should store gherkinLocations, matchedArgs, bodyFunction, andbodyLocation`
• Move all execution functions/methods into the sequential_test_case_executor.js module
  • Write loosely-couple functions or classes for execution of TestCase and TestStep; this will keep all the related execution code in one place, but keep each execution-scope as a distinct piece of code

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 of TestCase and TestStep; 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) create Test* 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.

If you are okay with this, @aslakhellesoy, I can start it and send a Pull Request.