[mbraendli]

Summary

Add doc string tests and example to verify handling of multiline doc strings and ensure compatibility with Cucumber-Ruby. Analysis, implementation, and tests were realized with Claude Code. Manual tests and reviews were done for all changes.

Details

• Added two wire protocol tests:
  • handlesInvokeMessageWithMultilineDocStringArg: Validates multiline doc strings with indentation and quotes.
  • passesDocStringArgToStepDefinition: Ensures doc strings are passed unchanged through WireProtocolHandler and CukeEngineImpl.
• Added a doc string example in FeatureShowcase covering scenarios without/with content type and one after a regex parameter.
• Note: Content type is not transmitted over the wire (consistent with cucumber-wire behavior).

Motivation and Context

The README currently warns about a bug in the wire protocol implementation (cucumber/cucumber-ruby#1183). While the underlying bug was fixed in Cucumber-Ruby 2.1.0, this repository lacked doc string coverage. This PR adds tests and examples to verify functionality. The README warning removal is handled separately in PR #320.

How Has This Been Tested?

• Environment: Linux (GCC 15, CUKE_STRICT=on).
• Unit Tests: All 113 tests pass (ctest 113/113).
• FeatureShowcase: Passes with Cucumber-Ruby 7.1.0.
• Compatibility: Doc string scenarios verified with Cucumber-Ruby 10.2.0 together with PR Support cucumber ruby 10 #320 (wire.rb support). PR Support cucumber ruby 10 #320 merges conflict-free with this PR (git merge-tree).
• CI: All workflows pass in fork PR Pending steps #3 (CI-Test for Doc string tests mbraendli/cucumber-cpp#3).

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).
• Additional tests

Checklist:

• It is my own work, its copyright is implicitly assigned to the project and no substantial part of it has been copied from other sources (including Stack Overflow). In rare occasions this is acceptable, like in CMake modules where the original copyright information should be kept.
• I'm using the same code standards as the existing code (indentation, spacing, variable naming, ...).
• I've added tests for my code.
• I have verified whether my change requires changes to the documentation
• My change either requires no documentation change or I've updated the documentation accordingly.
• My branch has been rebased to main, keeping only relevant commits.