LLFourn / bdk_core_staging

Staging area for bdk_core initial development
15 stars 12 forks source link

Testing blockchain examples #156

Open evanlinjin opened 1 year ago

evanlinjin commented 1 year ago

In the future, the examples will become individual modules/packages within the BDK repository. We want to test the functionally of the {}_example::Client methods to ensure the outputs is expected given different scenarios.

Although we want to test the Clients under the same set of scenarios, the syncing/scanning logic of each example is unique, so we want to check the outputs individually. Additionally, we may change the API of these Clients so we do not want to deal with the hassle of maintaining additional generic/wrapper code.

We will provide the Clients real blockchain data via the bitcoind and electrsd crates.

We will maintain a list of scenarios in this ticket description (I will update it via suggestions in the comments below).

Scenarios

rajarshimaitra commented 1 year ago

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

evanlinjin commented 1 year ago

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:

rajarshimaitra commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

notmandatory commented 1 year ago

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?

LLFourn commented 1 year ago

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.