02560ebb5f
* Log messages more granularely in node * Add pong message * Rework P2P service identifier The old implementation didn't catch the notion that service identifiers was a bit field where multiple services could be set at the same time. * Make Peer take InetSocketAddress Previously it took NetworkIpAddress. This doesn't make any sense, as we need to know the services bitfield to construct a NetworkIpAddress. * Clean up logs and toString methods * Clean up node README and main method * Make all networks final case objects * Skip publishing of wallet, node and chain * Clean up logging of node and chain modules * Add logging of max height in SpvNodeMain * Clean up Scaladoc and toStrings * Add logging configuration as symlinks in node We'll have to figure out a more stable solution to configure logging for the SPV node, but for the time being this is an acceptable solution. * Fix 2.11 compiler error |
||
|---|---|---|
| .. | ||
| src | ||
| build.sbt | ||
| README.md | ||
Philosphy of testkit
The high level of of the bitcoin-s testkit is to mimic provide functionality to test 3rd party applications.
There are other examples of these in the Scala ecosystem like the akka-testkit and slick-testkit.
We use this testkit to test bitcoin-s it self. For instance, our BitcoindRpcClient is tested with the functionality provided in the testkit. A quick example of a useful utility method is BitcoindRpcTestUtil.startedBitcoindRpcClient(). This spins up a bitcoind regtest instance on machine and generates 101 blocks on that node. This gives you the abililty to start spending money immediately with that bitcoind node.
We have similar utility methods for eclair.
Property based testing
There is also a robust set of generators available in the org.bitcoins.testkit.gen package. This allows you to integrate property based testing into your library and feel confident about implementing your application specific logic correctly.
You can see examples of us using these generators inside of testkit in our Private Key test cases