As I’ve been working on the implementation of cucumber-python, there has been one constant issue I keep running into. Whenever I want to tweak the output of the original microcuke implementation to make it more like the ruby implementation (i.e. include Features, Backgrounds, Tags, etc. in the output)—it requires significant reworking of existing code.
For microcuke to fulfill its promise as a minimal starting point for new ports, from which the port becomes stepping-stone towards a more full-featured implementation, I think it should much easier to add these extra bits of output.
Recommendation
I think the easiest way to do this would be to restructure microcuke as follows:
- keep the default output as-is (just Scenarios and Steps)
- make output more declarative; it should consist mostly of “wiring up” (i.e. mapping) objects to the information needed to print them
- colors to object types/statuses (i.e.
'green' for 'passed', 'cyan' for 'tag', etc.)
- indent to object types/statuses (i.e.
0 for Features, 1 for Scenarios etc.; Tags inherit their parent object’s indent level)
- a formatter, that accepts a format string, the object, colors, indentation, and any other info, and returns a string ready for printing
- the printer then prints the string
So, the printer should mostly just pass objects to the formatter—which does most of the work and returns a string—and then the printer prints it.
I believe this could be accomplished in a way that maintains microcuke’s small SLOC footprint, but makes it much more attractive to use for its intended purpose. With this type of structure, adding or tweaking output mostly becomes a matter of configuration, rather than code.
Whaddaya think?
As I’ve been working on the implementation of cucumber-python, there has been one constant issue I keep running into. Whenever I want to tweak the output of the original microcuke implementation to make it more like the ruby implementation (i.e. include Features, Backgrounds, Tags, etc. in the output)—it requires significant reworking of existing code.
For microcuke to fulfill its promise as a minimal starting point for new ports, from which the port becomes stepping-stone towards a more full-featured implementation, I think it should much easier to add these extra bits of output.
Recommendation
I think the easiest way to do this would be to restructure microcuke as follows:
'green'for'passed','cyan'for'tag', etc.)0for Features,1for Scenarios etc.; Tags inherit their parent object’s indent level)So, the printer should mostly just pass objects to the formatter—which does most of the work and returns a string—and then the printer prints it.
I believe this could be accomplished in a way that maintains microcuke’s small SLOC footprint, but makes it much more attractive to use for its intended purpose. With this type of structure, adding or tweaking output mostly becomes a matter of configuration, rather than code.
Whaddaya think?