Pre-history and motivation
We hardly use
cucumber_rust in our production projects having ~800 scenarios and recently have started to suffer from its limitations: no concurrent runner, inability to customize its parts without changing upstream code.
This PR is our long-going effort to make the
cucumber_rust extensible, customizable, while ergonomic and rational out-of-the-box for most cases. It represents an almost complete redesign and rewrite of the library with introducing some new features along and fixing many existing issues. It was battle-tested in our code base for quite a while, and showed significant improvements of test execution times. All the documentation, images and the Book are made up-to-date with the changes.
The new design of the library splits it to the 3 main components in the following pipeline:
Parser -> Runner -> Writter
Parser is responsible for sourcing
Scenarios for execution.
Runner is responsible for executing the stream of
Writer is responsible for outputting execution results.
All the 3 components may be customized or changed to a custom implementation, which solves any questions about implementing custom output, or custom execution order, or anything else.
Still the library provides reasonable defaults:
parser::Basic - reads from
.feature files and supports
# language: comment.
runner::Basic - executes all the scenarios concurrently by default (max 64 at the same time), and customizable to run fully (max 1 concurrent) or partially sequential (via
writer::Basic - simply outputs execution results to STDOUT, while
writer::Summarized are out-of-the-box wrappers introducing output order normalization and writing summary of execution (for anyone implementing custom
Writter to no bother about these problems).
We've also stripped from the default output the filenames and line numbers for successful steps, as from our experience they make the output unreasonable bloated and hard-to-read. We still keep them for failing steps, though.
macros feature is now enabled by default, as provides more ergonomic and understandable way to write step matchers.
rustc lints of the project are somewhat hardened and
clippy::pedantic lints are checked on CI now. We believe that tightening code style is beneficial for open source libraries and future contributions, despite it may mandate some strange or verbose situations in code.
Releasing and CI
Release process now is fully automated via GitHub actions. Just prepare the repository for a release, commit and push the appropriate version tag.
⚠️ ACTION REQUIRED: You should set the
CRATESIO_TOKEN to the project's GitHub secrets to release via CI.
CI now fully checks and tests the project, including the Book.
writer::Basic has really minimal output for success steps now.
#62: All the GIFs are ap-to-date now/
#63: We've tried our best to document everything pretty well, and enabled Clippy and
rustc lints to keep an eye on that.
#64: Possible by using regex now.
#71: Fixed and not applicable anymore.
#80: Parsing errors are now propagated to the
#86: Just fixed.
#88: Fixed and not applicable anymore.
#102: Now possible with
#103: Can be done by
writer::Basic pretty-prints only if terminal was detected.
#123: Now possible with
#126: Now uses
# language: comment to deduce language dynamically.
(partially) #50 and #127: While not provided out-of-the-box, may be implemented via custom
Contribution and maintaining.
We understand that this PR brings a huge impact to the library and may be undesirable by its author. If the later is true, we're OK to go on with our own fork and maintain it. However, from the Rust ecosystem perspective, it would be better to not introduce any ecosystem splits and disperse contributors efforts. That's why we also ask @bbqsrc to add me (@tyranron) and @ilslv to project maintainers, so we can continue to maintain the project and contribute to it more easily and actively. Ideally, we see the project to migrate to some GitHub org (like
cucumber-rs or smthng), where new maintainers may step-in to the project more easily in the future.