Open evanlinjin opened 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
bitcoind
regtest.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.
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:
TxOut
s indexed?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
.
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 andbitcoind
.
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.
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.
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?
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.
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
Client
s 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 theseClient
s so we do not want to deal with the hassle of maintaining additional generic/wrapper code.We will provide the
Client
s real blockchain data via thebitcoind
andelectrsd
crates.We will maintain a list of scenarios in this ticket description (I will update it via suggestions in the comments below).
Scenarios
Ensure
stop_gap
functions correctly. Does the methods correctly process a transaction history with self-sends right at the boundaries of the inputstop_gap
?If we provide the methods with "already-reorged" data, is the output as expected? I.e. Does the returned
SparseChain
/ChainGraph
contain checkpoints atagreement_point
andinvalid_from
indexes.