Closed johncantrell97 closed 2 years ago
Note: This tests sensei by directly invoking the AdminService and NodeService.
I think we still want e2e tests that can exercise the grpc and http endpoints. devrandom has a python script that uses the grpc api and I'm thinking of writing a quick node script that uses the http api.
I also want to get cypress tests running against the web-admin.
I think once all 4 of these are in place the project will be in a much better place from a testing standpoint going forward.
Ok this now also includes a bit of a refactor that extracts a "sensei core" lib as described here: #46
It also moves the integration test to the proper place in that library instead of a unit test.
This PR introduces a small refactor, a major bugfix, and a way to write integration tests for Sensei with a comprehensive example.
Small refactor is a cleanup where I removed the RequestContext object and just replaced it with the AdminService object. The RequestContext was redundant when really the http/grpc services just need access to the AdminService. I guess in theory in the future they might need access to other objects that don't belong as part of the AdminService but for now that's not the case and this is cleaner.
The bugfix is a bit complicated but it boils down to there being cases where Sensei can enter a deadlock because of the way tokio works. The fix ( for now at least) is to create a second tokio runtime that is used for performing synchronous database operations (used mostly by ldk persistence layer).
Most importantly I utilized the bitcoind crate to enable integration tests in sensei without needing to have any environment setup. Works fine with just
cargo test
and allows us to write tests that look like this:There's still some work to be done to enable polling /
wait_until
style code in the tests. Currently it's just waiting some amount of time for funding / channel opens / etc.I plan on add that functionality to this PR hopefully later today.