Design a plugin(-like) architecture for test drivers

[muggenhor]

Feature: test drivers as plugins
  In order to support multiple test frameworks
  As a developer
  I want to be able to add new test drivers easily, without needing to extend the core

Summarized

We're seeing quite some pull/feature requests for adding support for test framework X, Y and Z (e.g. #19, #20, #129, #142). In order to keep the core of cucumber-cpp maintainable I believe we need to be able to keep the support code for additional test drivers isolated from the rest. With isolated I mean: not intermingled with the rest of the source code, e.g. preferably grouped in a single directory per driver. Additionally this may help to make it possible to support out-of-tree test drivers.

[mattwynne]

@jermus67 what are your thoughts on this ticket?

[jermus67]

I would love to have something like plugin support / dependency inversion for supporting multiple test frameworks.

In order to support this I need to to grips what the current test framework support encompasses. From what I've seen so far it at least allows to use the test primitives from the framework, allowing you to use the various ASSERT_X like functions / macro's to throw exceptions that can be picked up by cucumber-cpp to mark a test (step) as failed. I don't know it also allows one to run the test as "part of the framework", i.e. that it allows output in a format that can be processed by the test framework to produce test reports, etc..

tl;dr I like this! I just need to understand what test framework support means in the context of cucumber-cpp :)

[jermus67]

I've done some drawing on what I think cucumber-cpp should become. Part of that idea is to drop the support for the wire protocol and (re)write the cucumber engine in C++ allowing the same features as in the other cucumber implementations. Also I'd like to extend the plugin architecture from supporting 3rd party library (initialisation) to step definitions as plugins. I hope the picture is clear enough, feedback is welcome.

[ursfassler]

The benefit would also be to distribute cucumber-cpp within a GNU/Linux distribution. At the moment, the package maintainer would need to choose about the test drivers. Activating all would install a lot of dependencies that are probably not needed by the user.

I haven't looked how this can be implemented, but would prefer a way where we don't need to write (and maintain) a cucumber C++ engine.