Create integration test with OPRETURN

[rajarshimaitra]

With recent merge of #105. We have OPRETURN output creation in bdk-cli.. This can be covered in the integration tests in tests/integration.rs using the regtsts-* backend.

[j-kon]

Hi, I’d like to work on this issue.

My plan is to add a focused integration test in tests/integration.rs covering OP_RETURN transaction creation through create_tx, using --add_string or --add_data, and then verify that the produced transaction contains the expected OP_RETURN output and payload.

If that sounds good, I’ll get started.

[vadim-anfv]

Hey @j-kon, thanks for your interest!

Before you dive in, heads up on the current state of tests/integration.rs:

1. All existing tests are commented out lines 248–258 – there are zero working integration tests right now.
2. The test framework is outdated – it references old feature flags (regtest-bitcoin, regtest-electrum) that no longer exist, and uses CLI commands (get_new_address, get_balance, sync) that have since changed.
3. There's also been a discussion about moving away from shelling out to the binary in tests in favor of calling handler functions directly.

The main BDK repo has a solid test infrastructure - bdk_testenv crate that spins up bitcoind + electrs programmatically via the electrsd crate, with auto-download of binaries and cleanup on drop.

I'd suggest splitting this into two PRs:

• PR 1: Set up a new test infrastructure - add bdk_testenv as a dev-dependency and write a basic integration test that calls handler functions directly (e.g. fund a wallet, check balance). This replaces the dead shell-based framework.
• PR 2 (follow-up): Add the OP_RETURN test on top of that - call create_tx handler with add_string / add_data, verify the resulting transaction contains the expected OP_RETURN output and payload.

Would you be up for tackling PR 1 first? Let us know if you have any questions.

[j-kon]

Thanks, that’s really helpful. I’m happy to take this on as two PRs:

• PR 1: replace the dead shell-based integration test setup with a working test infrastructure
• PR 2: add the OP_RETURN integration test on top of that

Before I start, I want to make sure I scope PR 1 the way you’d prefer:

1. Would you prefer the smallest possible setup for PR 1, meaning add bdk_testenv as a dev-dependency and get one basic funded-wallet integration test passing first, or should I shape the harness with multiple backends in mind from the start?

2. When you say “call handler functions directly,” would you like the tests to target the handler layer (handle_offline_wallet_subcommand / handle_online_wallet_subcommand), or go one level lower if that makes setup cleaner?

3. For PR 1, should I remove the dead shell-based framework in tests/integration.rs, or keep cleanup minimal and only replace enough of it to get the new path working?

4. For the first working test in PR 1, is a simple funded-wallet flow the right target (for example: fund wallet, sync, check balance / basic wallet operation), and then leave the OP_RETURN-specific assertions entirely for PR 2?

If that sounds good, I’ll proceed in those two steps.

[j-kon]

Also, just to make the implementation path explicit, here’s the plan I’m intending to follow for the two PRs.

PR 1

• Add bdk_testenv as a dev-dependency
• Replace the dead shell-based integration test setup with a minimal working harness
• Use the new harness to spin up the test environment programmatically instead of shelling out to the bdk-cli binary
• Call the relevant handler functions directly
• Start with one basic funded-wallet flow as the first working test (for example: fund wallet, sync, verify balance / basic wallet operation)

PR 2

• Build on the new test infrastructure from PR 1
• Add the OP_RETURN-focused test for create_tx
• Exercise the handler path with add_string and/or add_data
• Verify the resulting transaction/PSBT contains the expected OP_RETURN output and payload

The goal is to keep PR 1 as small and foundational as possible, then layer the OP_RETURN-specific coverage in PR 2.

cc @va-an @tvpeter

[tvpeter]

• Add bdk_testenv as a dev-dependency

Using the test_env is a good approach you can use.

• Call the relevant handler functions directly

Similar to how you are going to test the create_tx subcommand, you can test each subcommand as much as you can.

• Start with one basic funded-wallet flow as the first working test (for example: fund wallet, sync, verify balance / basic wallet operation)

The testenv (if you are using it) provides you with a funded wallet. But when you start, you will get more clarity.

[j-kon]

Thanks, I’ve been assigned the issue and I’ll proceed with PR 1 first.

I’ll use bdk_testenv for the new harness, call the handler functions directly, and start with the basic funded-wallet flow as the first working test. I’ll keep the setup reusable so I can build the OP_RETURN coverage on top of it in PR 2.

[j-kon]

I’ve opened PR 1 for the new integration test infrastructure here: https://github.com/bitcoindevkit/bdk-cli/pull/267\n\nThis PR sets up the -based harness, switches integration tests to call handlers directly, and adds the first funded-wallet flow test. I’ll follow up with PR 2 for the OP_RETURN-specific coverage on top of this foundation.

[j-kon]

I’ve opened PR 1 for the new integration test infrastructure here: #267

This PR sets up the bdk_testenv-based harness, switches integration tests to call handlers directly, and adds the first funded-wallet flow test. I’ll follow up with PR 2 for the OP_RETURN-specific create_tx coverage on top of this foundation.

[tvpeter]

Closing this issue as resolved as some integration tests introduced in #289 covered this. Specifically, this test covered this issue.

Please feel free to reopen the issue if you think it was not properly addressed.