Create integration test with OPRETURN #120

Activity

1. rajarshimaitra

   added

   good first issueGood for newcomersGood for newcomers

   testUnit and Integration testingUnit and Integration testing

   on Sep 22, 2022
2. notmandatory

   added this to BDK-CLIon Sep 26, 2022
3. notmandatory

   moved this to Todo in BDK-CLIon Sep 28, 2022
4. j-kon commented on Apr 3, 2026

   

   j-kon

   on Apr 3, 2026

   More actions

   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.
5. vadim-anfv commented on Apr 3, 2026

   

   vadim-anfv

   on Apr 3, 2026

   Collaborator

   More actions

   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.
6. j-kon commented on Apr 3, 2026

   

   j-kon

   on Apr 3, 2026

   More actions

   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.
7. j-kon commented on Apr 3, 2026

   

   j-kon

   on Apr 3, 2026

   Last edited by j-kon

   More actions

   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
8. tvpeter commented on Apr 3, 2026

   

   tvpeter

   on Apr 3, 2026

   Collaborator

   More actions

   • 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.
9. tvpeter

   assigned

   j-kon

   on Apr 3, 2026
10. j-kon commented on Apr 3, 2026

    

    j-kon

    on Apr 3, 2026

    More actions

    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.
11. j-kon commented on Apr 3, 2026

    

    j-kon

    on Apr 3, 2026

    More actions

    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.
12. j-kon commented on Apr 3, 2026

    

    j-kon

    on Apr 3, 2026

    More actions

    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.
13. tvpeter commented on Jul 19, 2026

    

    tvpeter

    on Jul 19, 2026

    Collaborator

    More actions

    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.
14. tvpeter

    closed this as completedon Jul 19, 2026
15. github-project-automation

    moved this from Todo to Done in BDK-CLIon Jul 19, 2026