test: add Rust integration test framework for lianad

[jp1ac4]

This adds a Rust integration test framework for lianad, which will allow to test lianad's Rust APIs in integration tests as a complement to the Python tests, which test lianad's RPC commands.

As an initial example, the Python test test_spend.py::test_spend_change has been added as a Rust test.

The new Rust test has been added to the existing CI task that runs the Python functional tests.

Note that electrsd is not yet supported on Windows and so the new lianad/tests/ folder will be excluded from this target OS.

With the new lianad/tests folder, there was an error when running the unit tests on Windows due to a missing main() function in the liana-cli crate, so I added a commit to compile a placeholder binary for Windows. I think the presence of the lianad/tests folder triggers the compilation of all crates which then led to this error, but I'm not sure why it didn't happen for normal builds.

[pythcoiner]

Using this Rust test framework, it should be possible to port all (or most) of the other Python functional tests to Rust, which should then avoid the need for #1007 and #1477.

Well I guess the original intent of writing tests in python was done on purpose: testing against a different language+implementation.

I'm really not sure we want to get rid of those python tests, even if I'd personally prefer deal with rust test from a personal POV (this is mainly for comfort/efficiency), I think our python test suite is important from a security POV.

[darosior]

Well I guess the original intent of writing tests in python was done on purpose: testing against a different language+implementation.

Indeed. Having functional tests in another language allows cross checking, which may catch bugs and suboptimal design decisions. For instance, having the functional tests use a Python client for the RPC interface may catch an implicit behaviour of the Rust serialization crate, that would go unnoticed if the functional tests were in the same language. Similarly, using a different language and/or implementation¹ to parse descriptor/PSBTs, sign, etc may reveal bugs or implicit design assumptions. I do remember that the Python functional revealed some of those for me. Some were issues after the fact (that i can't find on Github right now), but most were during the development of the feature.

That said, all of this cross checking does comes at a cost. Not reusing the same JSON library, the same RPC client, the same bitcoind HTTP client, the same libraries for PSBT / descriptor serialization and for signing, does allow you to cross check the Rust implementation in the wallet, but does mean you need to implement and maintain all this duplicate logic. I was willing to maintain those, certainly because most of those were things i was either familiar with (from the C-Lightning or Bitcoin Core functional framework) or that i had implemented myself anyways (BIP 32 and descriptor / Miniscript parsing + satisfaction logic). I can understand that it may be a heavier burden to bear for the current maintainers, and that this time may be better invested in alternative ways of hardening the software.

Another point may be that there is diminishing marginal returns to maintaining an entire functional test suite in a different language. It was useful in the early days of the software, when we had a lot less users and testing, and were implementing core components that benefited from an alternative implementation. It might also be the case that we can rip a large part of the benefits for a much smaller fraction of the cost, for instance by only keeping some basic sanity checks of the interface in Python?

TL;DR: there are benefits to having the functional tests in a separate language. Those don't come for free. You guys bear the maintenance burden now, so you make the call. :-)

Footnotes

1. Or a different method, such as a Bitcoin Core wallet, that we sometimes use in the functional tests. ↩

[jp1ac4]

Thanks for outlining these points for consideration.

My main motivation for porting the functional tests to Rust was for increased efficiency when writing tests and to reduce the burden of maintaining/extending the Python framework. But I understand from your summary that there can be advantages to using a different language and so there's a trade-off between the two.

One other possible benefit of having the functional tests in Rust is that it allows to test lianad's Rust APIs, which we expect are used much more often than the RPC commands (i.e. via the GUI), so in that sense I feel it's worth having both the Python and Rust functional tests.

[jp1ac4]

Based on the comments above, I've reworded the PR title and description to indicate that the Rust integration test framework is not necessarily intended to replace the Python tests.