CODEWITHSUNDEEP
corda
nimmaj
nimmaj

Reputation: 105

Integration testing transaction outputs on the @InitiatedBy side post transaction finality

I have a situation where I have an @InitiatingFlow, called ProposeMemberFlow, and a corresponding @InitiatedBy ProposeMemberFlowResponder. I would like include in my integration test something that tests that the responder has one of the transaction output states post the FinalityFlow sub flow having been kicked off by the initiating flow.

I naively called waitForLedgerCommit in the responding flow, post responding to the CollectSignaturesFlow, but I'm finding that the initiating flow finishes before the responding flow does - presumably the latter is waiting for the vault update.

I'm integration testing through a CordaService - is "the corda way" to use expectEvents to wait for VaultUpdates so that I then know when it's safe to test against the CordaService? Much like here?

Thanks

Upvotes: 2

Views: 139

Answers (1)

Joel
Joel

Reputation: 23140

I haven't heard of integration testing via a CordaService. Generally, you would write integration tests using the node driver.

Here's an example: https://github.com/corda/cordapp-template-kotlin/blob/release-V2/cordapp/src/integrationTest/kotlin/com/template/DriverBasedTest.kt

This piece of code starts a set of nodes, then uses RPC to check some conditions of the node.

In your case, you'd want to use the following set of RPC operations in the node driver:

  • CordaRPCOps.startFlowDynamic on node A's RPC handle to run the ProposeMemberFlow
  • CordaRPCOps.vaultQueryBy on node B's RPC handle to check that the correct state has been written to the vault

Another option would be to use the mock network (e.g. https://github.com/corda/cordapp-example/blob/release-V2/kotlin-source/src/test/kotlin/com/example/flow/IOUFlowTests.kt). You could argue that this isn't an integration test, since you are running mock nodes instead of real nodes. However, the mock nodes are just another implementation of the AbstractNode interface, and should behave like normal nodes for the purposes of testing.

Upvotes: 0

Related Questions