WANTED: A new maintainer 🔧🙋‍♀️🙋🏾‍♂️🙋🏼

[mattwynne]

This project has had pull requests piling up for a few years now.

There are some active forks so clearly people are using still it, but we sadly don't have anyone here within the Cucumber org taking responsibility for keeping this copy up to date.

I haven't seen @paoloambrosio or @muggenhor around these parts in a while, so I suspect we may be looking for a new maintainer (or two!). None of the rest of the core team use C++ regularly, so we really need someone who uses the tool to help us look after it.

@jermus67, @rogerdubbs, @silvergasp, @dmeehan1968, @saimusdev you've all made commits on your own fork fairly recently. Would any of you be interested in helping keep this library up to date? Or do you have any friends who might? 😁

In return, you will get the 🎉 and ❤️ of the Cucumber community, and a great new way to spend your spare time 😄

[silvergasp]

I'm happy to help out, here and there with reviews, but my windows of spare time are fairly limited at the moment. Not so sure if I want to take on the role of 'the maintainer' though.

[dmeehan1968]

I doubt I'd have the time to be honest. I keep revisiting cucumber for various different projects but find that it never sticks, largely because I keep running into incompatibilities regardless of language. Most recent project was to investigate its usefulness for testing in embedded, but I found the wire support so poorly documented and implemented across the various runners that it wasn't worth the effort.

[silvergasp]

@dmeehan1968 I have also been looking at doing something similar with cucumber for embedded development. It'd be great to see where you got with it. I've got a few ideas as to how this could work. But it would be better to spin that out into a separate discussion.

[paoloambrosio]

I haven't maintained the software in at least a couple of years, and very little in the two years before that. Haven't been reading the Cucumber Slack workspace in years either.

Cucumber-CPP started as a way of defining executable specifications for a software that I was working on. Not much after, that software died but I kept working on this. I'm not a C++ developer, and it's really difficult to be a maintainer of something you don't use.

I wish the best to all future maintainers of this project. Creating software used by others around the world was an amazing experience. The guys of the core team are amazing people, and well deserve the success they had.

Guess this is goodbye... 👋🏻 😢

[dmeehan1968]

@silvergasp i don't have anything to shoe for it. I scoped it out but just got frustrated with it.

The main thing I wanted it for was encouraging the client to define behaviours, and then use that to automate some of the testing. It's for an IoT device and so there's questions there about how much to mock vs treat as an integration test, plus whether it's reasonable to end-to-end test given the wireless duty cycle restrictions.

I didn't really want to build step definitions into the product, even in a debug/dev build, so I was thinking more of 'injecting' sensor readings, and having a way of accelerating time.

The product development has been in C, and I didn't want to get into C++ and wondered about using one of the other cucumber flavours as a test runner. I am considering C++ for new developments, in which case I might come back to this.

[jermus67]

I'm interested, but I have to do both some soul searching if I'm willing to, and figuring some legal stuff out with my employer, before I can commit myself to participate in maintaining an open source project.

And thanks @paoloambrosio , for the work you did put into it 🥇, and goodbye. I'm quite happy using this library at home (mainly with google test, and in small test- and fiddling-things-out-projects, but still ...).

[jermus67]

Hello @mattwynne,

I'm interested and willing to step in as maintainer. I'll try to give a little background about myself and my interest in cucumber-cpp.

I'm a software engineer with a bit over 20 year experience in the industry (and a bit over 30 years in software development if you take the years before that als into account). I have worked mainly with shell-scripting, C and Java, and I am currently moving to mainly using C++. My field of expertise is middleware and software platforms, defining abstractions so that application developers can use a stable API towards concepts, allowing the software platform to adapt to the current technology of choice without bothering the software developers (too much).

My interest in cucumber fits in the "applying abstraction" category, in that it forces you to think a little different about testing and it also has the potential of producing actual human readable tests. I have done a few projects with cucumber-java, and I liked the results (some tests are indeed actually readable).

At my day-time job we mainly use GTest for (unit) testing, and cucumber-java for integration / requirements testing. Since the main programming language in the current projects is C++, having to program test steps in a different language (i.e. java) than the main project language has made some developers express the desire for Gherkin based testing using C++ as implementation language for the test steps. In my own fork I managed, with a few tweaks, to get the GTest part of cucumber-cpp to work with GTest 1.10.0 and CMake 3.19.x (I noticed that I needed to adjust the cmake configuration files post-install to make them work with cmake's find_package() function).

Since at work we mainly work with GTest / CMake, my main focus on maintaining this project will be on this combination. I have no experience with the Boost unit test environment, nor with QtTest. If maintaining is solely up to me I don't think I could mean much for those two environments.

Since quite some aspects of Boost have been moved into the C++ standard (runtime library), I think it would be a good thing to investigate what parts of the Boost dependencies could now be replaced by elements from the standard. That'd be a nice exercise. To simplify maintenance it may also be wise to narrow the default support for a testing framework in the future down to one (guess which one I would like choose 😉), separated by a (well-documented) interface to allow adding your own flavour of test engine, be it Boost, QtTest or CGreen (I didn't know that one, it was mentioned in #243).

There are also some things in the project that I cannot place yet, e.g. travis, appveyor and some ruby files of which I don't know the exact function yet, but I think that with a little help I could come a long way.

The legal stuff can be arranged too. Since my contract contains an "all your code are belong to us" clause I need to (digitally) sign a statement in which both I and the company I work for agree to hand over IP to the project of the code I will be contributing, and that we allow the code to be released under the license of the open source project (I hope I did phrase this in proper legalese, but I do think you will get what I mean).

I hope to hear from you soon.

(I have no idea how things like this are normally arranged - provided your are willing to take me in as maintainer, of course).

Kind regards, @jermus67

... who hopes that this doesn't read too much like a desperate application letter.

[mattwynne]

@jermus67 that's wonderful! Thank you. What timezone are you in? Would you like to arrange a time to chat in Slack or even on a Zoom call? I'm on PST. @silvergasp thanks also for your kind offer - the more people involved, the better so please stick around and contribute what you can!

@dmeehan1968 I'd be interested to hear more about your woes trying to use the wire protocol, and what we could do about it. I've heard some amazing stories of people using Cucumber to test embedded systems and I'd love to see if we could help.

[mattwynne]

@paoloambrosio thanks for swinging by to tell us what you're up to, and thanks for all the hard work you put in over the years. I hope we can share a beer again sometime. Gracie!

[dmeehan1968]

@mattwynne

I'd be interested to hear more about your woes trying to use the wire protocol, and what we could do about it. I've heard some amazing stories of people using Cucumber to test embedded systems and I'd love to see if we could help.

The premise of the wire protocol seems to be to put the step definitions in the target system. i.e. the wire protocol is designed to serialise the process of matching steps too definitions that test the application logic. Whilst this allows you to test code running on the actual platform, this is more about testing the tool chain than the logic of the application. A lot of embedded systems just couldn't handle the code overhead, and then you've got the issue of whether its at all desirable to use dynamic (heap) allocation on a target.

As I've mentioned in #243, the best I've been able to come up with is to allow the step definitions to 'observe' the target. Given that devices I've been working with are headless, for development purposes its been useful/necessary to build in a serial debug output (we use the serial for device configuration too so not redundant). In fact, we are proposing that in future we add an infrared interface, because the physical connection of a serial line can affect the products power and wireless performance).

The presence of the serial interface can be used either as a simple observer, and/or as a simple command interface, such that a test running/step definition could send commands to the device which either solicit debug output or control the device, such as to invoke a restart, or inject sensor inputs etc.

Where I see Cucumber as useful is in the specification of acceptance tests, which can be applied against a release build (or as close as possible). For the type of sensor devices I've been working with, significant elapsed is required, as the normal reporting cycle is hourly, and functional cycles might be daily or longer. Therefore ideally I'd like to be able to manipulate the RTC of the device to accelerate time, but even with 'real time', a significant amount of acceptance testing could be performed by running tests in parallel across multiple devices over a period of a few days.

The devices also use a lossy wireless network to report data, and as a result, tests would be brittle if we relied on end-to-end arrival, but by observing what the debug output 'says' is happening, we'd get a lot of validation. We could always implement retries into the step definitions/scenarios or aggregate test runs if we need to cope with the lossy nature.

One thing that's been common in my experience of investigating Cucumber over the years is that I've found it really hard to find real world examples of Cucumber usage. That's limited my own ability to see how other people might have solved some of the challenges that I see. Some of that will be due to commercial secrecy, but searching say Github for '.feature' files really only reveals experiments. Maybe its just not in the realm of open source, and maybe that's just a reflection of the stakeholders being more technical and not needing a DSL to describe requirements (code based unit tests are readable to the intended audience).

[jermus67]

@jermus67 that's wonderful! Thank you. What timezone are you in? Would you like to arrange a time to chat in Slack or even on a Zoom call? I'm on PST. @silvergasp thanks also for your kind offer - the more people involved, the better so please stick around and contribute what you can!

@mattwynne, my timezone is CET (currently UTC+2, and I just checked, you're now UTC-7, that is a nice difference 😄). I would like to arrange a time to chat. Late mornings for you corresponds to my early evenings, so I think that that would be a good time slot to arrange a chat in. I'm - as yet - unfamiliar with Slack, so I would prefer a chat in Zoom. Do you know what the best way is to exchange contact details without potentially exposing them to the complete internet population?

[mattwynne]

Late mornings for you corresponds to my early evenings, so I think that that would be a good time slot to arrange a chat in

👍

Do you know what the best way is to exchange contact details without potentially exposing them to the complete internet population?

Probably drop me an email at the address on my GitHub profile and we can go from there?

It's worth figuring out Slack. Most of the other committers hang out in there and it can be a nice place to chat semi-synchronously. If you head https://cucumberbdd-slack-invite.herokuapp.com and put your email in, it will send you an invite.

[mattwynne]

Thankyou @jermus67 for stepping forward!

Now that his employer has given formal approval I think we can close this issue

Everyone else who's interested, please don't go anywhere - the more people helping out and sharing the work the better. ❤️

[remichristiaan]

@jermus67, are you the maintainer of cucumber-cpp? This because on this page it's still listed as unmaintained.

[remichristiaan]

@mattwynne, can you shed light on this matter?

[mattwynne]

Hi @remichristiaan. You're right, @jermus67 has previously agreed to take on this role, though I'm not sure how much time he's been able to devote to it recently.

Are you interested in helping out?

[jermus67]

Hi @remichristiaan (, and @mattwynne ),

I indeed previously agreed to take on this role. I managed to do something, and than life happened. I have not been able to spend any time on it lately, and I don´t foresee to be able to spend much time on it in the coming future also. With that in mind the page you referred to reflects the status rather accurately.

Feel free to step in. The project can really do with a bit more attention, as BDD is the way I test and specify behavior at work (just no longer with C++ as test environment, that´s why interest has dropped).

Regards, Jeroen

[remichristiaan]

Hi @mattwynne and @jermus67,

We're currently investigating Cucumber-cpp for use in our process and some work was done to get it up-to-date with using the latest cucumber version and some other details. This work can be put in a PR when everything checks out, not sure if we can pick up the maintainer role due to bandwidth issues.

[mpkorstanje]

In light of @jermus67 comments I'm reopening this issue.

[luke-hill]

For those asking about wire implementation issues too. We have released about 3/4 new (major), wire versions and I know @ursfassler has done some work getting the Gemfile a lot more conformant.

I'm happy to try help wherever possible with any wire integration stuff. But I won't be able to support anything on the c++ side.

[ursfassler]

Hi all, I am interested to become a maintainer. Mainly because I regularly use cucumber-cpp and I like to modernize it a bit. As I'll do it in my spare time I can't say how much and long I can do it.

The projects where I use cucumber-cpp for work are usually in the area of Embedded Linux applications, some with Qt and some pure C++. To shorten the feedback loop I don't run the test-applications on the embedded device :wink: . I like to use Gherkin instead of a unit test framework because it helps focusing on the behavior of the test. The result is an easy to understand documentation. And it even happened that I used it to discuss the behavior with customers.

For the near future I'd like to see cucumber-cpp to be a modern C++/CMake project. Also a better separation of the assertion library may be a good idea. And new ideas and request will come :smiley:.

[mattwynne]

That's great to hear @ursfassler. I love that you have a vision for where to take the code, and the skills to make it happen!

If you'd like to talk more about this, you can book me at https://calendly.com/mattwynne. Don't forget you can also find a bunch of us in the #committers channel in Slack.

[ursfassler]

Closing as I take over maintainership. Happy to have more.

[mattwynne]

Welcome @ursfassler!

[int19h]

The "unmaintained" label on https://cucumber.io/docs/installation/ should be updated accordingly.

[mattwynne]

@int19h thanks for spotting that, would you like to make the change?