test(bdd): add C++ SDK BDD tests for basic messaging#3554
Conversation
|
@seokjin0414 the test should be in he root bdd/ folder, not inside of foreign/cpp |
9d6f66a to
d670d13
Compare
|
ignore the above, i didn't read the description😅 |
The oversized-payload test grew its 64 MB buffer one byte at a time and a comment claimed cxx::Vec had no public reserve API. It does, so reserve the capacity once before filling it. Signed-off-by: seokjin0414 <sars21@hanmail.net>
d670d13 to
dfc8f20
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3554 +/- ##
============================================
- Coverage 74.41% 74.39% -0.03%
Complexity 937 937
============================================
Files 1243 1243
Lines 125987 125987
Branches 101854 101901 +47
============================================
- Hits 93756 93726 -30
+ Misses 29218 29201 -17
- Partials 3013 3060 +47
🚀 New features to boost your workflow:
|
dfc8f20 to
0e70305
Compare
|
@slbotbm |
|
@seokjin0414 I didn't understand why did you use cmake instead of bazel. I think it would be possible to use bazel in bdd/cpp. you could define |
|
/author |
The C++ SDK had no BDD coverage. Add cucumber-cpp step definitions under bdd/cpp that drive the shared basic_messaging.feature through the C++ FFI client. cucumber-cpp uses the wire protocol, so bdd/cpp is a self-contained Bazel module: it builds the step definitions into a wire server (pulling cucumber-cpp from the Bazel registry and the Iggy C++ SDK from foreign/cpp via local_path_override) that a Ruby Cucumber runner connects to. The SDK's iggy-cpp target is made public so the harness can depend on it. A per-file CUKE_OBJECT_PREFIX keeps the generated step classes from clashing across translation units. The Gemfile and cucumber.wire comment styles are registered with the license checker. Signed-off-by: seokjin0414 <sars21@hanmail.net>
A Ruby cucumber runner with cucumber-wire drives the wire server over the wire protocol against a real iggy-server. Register the cpp-bdd compose service, the run-bdd-tests entry, and the bdd-cpp CI component so it runs like the other SDK BDD suites. Signed-off-by: seokjin0414 <sars21@hanmail.net>
0e70305 to
533c9b0
Compare
|
@slbotbm the cmake route was just to keep the test self-contained in bdd/cpp without touching foreign/cpp — i didn't realize local_path_override could pull the sdk in cleanly. it can, so i switched to bazel as you suggested: bdd/cpp is its own module now, cucumber-cpp from the registry + iggy_cpp via local_path_override(../../foreign/cpp). cmake is gone. the only change to foreign/cpp is one line — making the iggy-cpp target public so the harness can depend on it. build + the full wire e2e (17 steps) pass. |
What
Adds BDD coverage for the C++ SDK by implementing the shared
bdd/scenarios/basic_messaging.featurewith cucumber-cpp and wiring it into theDocker-based BDD harness and CI, the same way the other SDKs run. This is the
second part of #2965; the messaging FFI it relies on landed in #3046.
How it works
cucumber-cpp only supports the Cucumber wire protocol, so the step definitions
(
bdd/cpp/features/step_definitions) build with CMake into a wire server, and aRuby Cucumber runner (
cucumber+cucumber-wire, pinned to the versionscucumber-cpp itself tests against) drives the feature file over the wire against a
real
iggy-server. The step logic and assertions are all C++ and exercise theSDK's FFI (
get_streams,create_stream,create_topic,send_messages,poll_messages). The Iggy C++ SDK is built with cargo and linked into the wireserver as a staticlib.
Heads-up for reviewers
Because cucumber-cpp is wire-protocol-only, the C++ BDD image pulls in a Ruby
runtime (
cucumber+cucumber-wire). Flagging this explicitly in case itchanges how you'd like the harness shaped.
Notes
Everything lives under
bdd/cpp, next to the other SDK BDD suites;foreign/cppis unchanged apart from the reserve() fix to the existing test.
The TearDown fixture and the magic-number cleanup discussed on Discord are tracked
separately by @slbotbm.
Refs #2965