Testing blockchain examples

[evanlinjin]

Testing blockchain examples

[notmandatory]

Hey all just a reminder that @danielabrozzoni and I are in Nashville so may not get too much testing done this week, but I propose to help us divide and conquer we each focus on one of the blockchain clients and do at least one or two manual + integration tests .. and as we go along we can compare approaches and results. Would this division work for everyone?

• electrum: @notmandatory
• esplora: @vladimirfomene
• rpc: @rajarshimaitra
• cbf: @danielabrozzoni

[rajarshimaitra]

We should first cover all the basic tests included in the BDK blockchain tests before considering all the edge cases of bdk_core.

We can organize them in a separate integration test module following the standard integration test guidelines of rust.. https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/second-edition/ch11-03-test-organization.html#integration-tests

This will include

• The test framework with bitcoind regtest.
• Helper functions to scan the tracker with bitcoin core RPC. Code already available in the RPC example PR.
• Include all the tests covered in BDK's Blockchain module.

More tests covering edge cases and other behaviors not covered by the BDK wallet can be added to the same test module.

[evanlinjin]

Helper functions to scan the tracker with bitcoin core RPC. Code already available in the RPC example PR.

Why would this be necessary when we are testing Electrum/Esplora?

---

I think it will make sense to focus on the result of scanning/syncing in BDK Core. Some tests in BDK don't have this focus.

We want to have a pre-existing history of transactions under a descriptor, and sync BDK Core with it and call methods on the tracker to see if it makes sense.

An example checklist will be the following:

• Are all TxOuts indexed?
• Do all relevant transactions exist in sparsechain?
• Is the returned UTXO set correct?
• Is the balances correct?
• Are the checkpoints correct? Do they exist in the "real" history?
• Is the last used index, next unused undexes correct?

[rajarshimaitra]

Removing myself as I will only be able to focus on testing for one example and preferably RPC.

I am not fully clear on some points like If we provide the methods with "already-reorged" data as there doesn't seem to be any method taking in any blockchain-related data. But looking forward to seeing the full scenario list, and I will try to reproduce them with RPC example and bitcoind.

[evanlinjin]

Removing myself as I will only be able to focus on testing for one example and preferably RPC.

I am not fully clear on some points like If we provide the methods with "already-reorged" data as there doesn't seem to be any method taking in any blockchain-related data. But looking forward to seeing the full scenario list, and I will try to reproduce them with RPC example and bitcoind.

No worries Raj.

Methods take in checkpoints. That is "Blockchain-related" data. We emulate a situation when we already have pre-existing data existing before call to the methods.

[rajarshimaitra]

Methods take in checkpoints. That is "Blockchain-related" data. We emulate a situation when we already have pre-existing data existing before call to the methods.

Okay. If I am thinking right, then we can also do the same by reorging bitcoind and resanning with the previous chain-state of the tracker. Won't that be a more "real" scenario than trying to feed the data manually in the wallet_txid_scan function?

Anyway, I think it will be clearer to talk over code than words. I will try to sketch up something by the end of the week.

[LLFourn]

I think esplora, electrum and the bitcoin rpc wallet are ready to test. What it exactly means to test CBF is not really clear to me. The only thing I can think of is that there is a API in CBF that when given a list of checkpoints (block height and hash) returns a stream of blocks starting at the block after the last checkpoint it found that is still in the chain.