yyforyongyu d9498a9d13 lntest: increase DefaultTimeout for postgres | vor 3 Monaten | |
---|---|---|
.. | ||
channels | vor 3 Jahren | |
mock | vor 4 Monaten | |
node | vor 4 Monaten | |
port | vor 6 Monaten | |
rpc | vor 4 Monaten | |
unittest | vor 6 Monaten | |
wait | vor 3 Monaten | |
README.md | vor 6 Monaten | |
bitcoind.go | vor 2 Jahren | |
bitcoind_common.go | vor 4 Monaten | |
bitcoind_notxindex.go | vor 2 Jahren | |
bitcoind_rpcpolling.go | vor 2 Jahren | |
btcd.go | vor 4 Monaten | |
doc.go | vor 6 Jahren | |
fee_service.go | vor 4 Monaten | |
harness.go | vor 3 Monaten | |
harness_assertion.go | vor 5 Monaten | |
harness_miner.go | vor 4 Monaten | |
harness_node_manager.go | vor 6 Monaten | |
harness_setup.go | vor 6 Monaten | |
neutrino.go | vor 1 Jahr | |
utils.go | vor 3 Monaten |
lntest
lntest
is a package which holds the components used for the lnd
’s
integration tests. It is responsible for managing lnd
nodes, chain backends
and miners, advancing nodes’ states and providing assertions.
A simple example to run the integration test.
func TestFoo(t *testing.T) {
// Get the binary path and setup the harness test.
//
// TODO: define the binary path to lnd and the name of the database
// backend.
harnessTest := lntemp.SetupHarness(t, binary, *dbBackendFlag)
defer harnessTest.Stop()
// Setup standby nodes, Alice and Bob, which will be alive and shared
// among all the test cases.
harnessTest.SetupStandbyNodes()
// Run the subset of the test cases selected in this tranche.
//
// TODO: define your own testCases.
for _, tc := range testCases {
tc := tc
t.Run(tc.Name, func(st *testing.T) {
// Create a separate harness test for the testcase to
// avoid overwriting the external harness test that is
// tied to the parent test.
ht := harnessTest.Subtest(st)
// Run the test cases.
ht.RunTestCase(tc)
})
}
}
This package has four major components, HarnessTest
, HarnessMiner
,
node.HarnessNode
and rpc.HarnessRPC
, with the following architecture,
+----------------------------------------------------------+
| |
| HarnessTest |
| |
| +----------------+ +----------------+ +--------------+ |
| | HarnessNode | | HarnessNode | | HarnessMiner | |
| | | | | +--------------+ |
| | +------------+ | | +------------+ | |
| | | HarnessRPC | | | | HarnessRPC | | +--------------+ |
| | +------------+ | | +------------+ | | HarnessMiner | |
| +----------------+ +----------------+ +--------------+ |
+----------------------------------------------------------+
HarnessRPC
holds all the RPC clients and adds a layer over all the RPC
methods to assert no error happened at the RPC level.
HarnessNode
builds on top of the HarnessRPC
. It is responsible for
managing the lnd
node, including start and stop pf the lnd
process,
authentication of the gRPC connection, topology subscription(NodeWatcher
)
and maintains an internal state(NodeState
).
HarnessMiner
builds on top of btcd
’s rcptest.Harness
and is responsible
for managing blocks and the mempool.
HarnessTest
builds on top of testing.T
and can be viewed as the assertion
machine. It provides multiple ways to initialize a node, such as with/without
seed, backups, etc. It also handles interactions between nodes like
connecting nodes and opening/closing channels so it’s easier to acquire or
validate a desired test states such as node’s balance, mempool condition,
etc.
Standby nodes are HarnessNode
s created when initializing the integration test
and stay alive across all the test cases. Creating a new node is not without a
cost. With block height increasing, it takes significantly longer to initialize
a new node and wait for it to be synced. Standby nodes, however, don’t have
this problem as they are digesting blocks all the time. Thus it’s encouraged to
use standby nodes wherever possible.
Currently there are two standby nodes, Alice and Bob. Their internal states are
recorded and taken into account when HarnessTest
makes assertions. When
making a new test case using Subtest
, there’s a cleanup function which
further validates the current test case has no dangling uncleaned states, such
as transactions left in mempool, open channels, etc.
lntest
Since the miner in lntest
uses regtest, it has a very fast block production
rate, which is the greatest difference between the conditions it simulates and
the real-world has. Aside from that, lnd
has several places that use
different code, which is triggered by the build flag integration
, to speed up
the tests. They are summarized as followings,
funding.checkPeerChannelReadyInterval
, which is used when we wait for the
peer to send us ChannelReady
. This value is 1 second in lnd
, and 10
milliseconds in lntest
.lncfg.ProtocolOptions
, which is used to specify protocol flags. In lnd
,
anchor and script enforced lease are enabled by default, while in lntest
,
they are disabled by default.lntest
. In lnd
, the parameters N,
R, and P are imported from snacl
, while in lntest
they are replaced with
waddrmgr.FastScryptOptions
. Both macaroon
and aezeed
are affected.nextRevocationProducer
, defined in LightningWallet
is
slightly different. For lnwallet
, it will check a special pre-defined
channel ID to test restoring channel backups created with the old revocation
root derivation method.