Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design a plugin(-like) architecture for test drivers #154

Open
muggenhor opened this issue Jun 3, 2017 · 4 comments
Open

Design a plugin(-like) architecture for test drivers #154

muggenhor opened this issue Jun 3, 2017 · 4 comments

Comments

@muggenhor
Copy link
Contributor

muggenhor commented Jun 3, 2017

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
Copy link
Member

@jermus67 what are your thoughts on this ticket?

@jermus67
Copy link
Contributor

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
Copy link
Contributor

jermus67 commented Mar 8, 2022

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.

Cucumber-CPP - CucumberCpp

@ursfassler
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants