ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-02-12 05:35:50 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Incorporating PR review feedback.

Browse Source
This commit is contained in:
josecoll 2018-04-24 19:14:14 +01:00
parent 4c3d223d5a
commit 685897a7d2
6 changed files with 21 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
testing/qa/behave/compatibility/README.md
View File

@ -5,7 +5,7 @@ Compatibility / Interoperability testing refers to validating the run-time behav
components within the Corda Platform and ensuring that data is compatible, both "on the wire" (P2P AMQP and RPC Kyro
serialization forms) and "at rest" (persisted to a database) between collaborating components.
Compatibility testing focuses at three different levels:
Compatibility testing focuses on three different levels:
1. Corda Network (Compatibility Zone - level, Doorman, Notary)
2. Corda Node (eg. participant nodes, oracles)
@ -21,7 +21,7 @@ Components within scope for this level of testing include:
The following aspects of a Corda Network are configurable/changeable over time and require validating via CTS coverage:
- Permissioning: provision of an identity certificate signed by the networks root CA
- Permissioning: provisioning of an identity certificate signed by the networks root CA
- Network Parameters changes (such as adding/removing a Notary, whitelisting CorDapps for constraint checking),
and distribution to nodes via bootstrapper (OS) / HTTP NMS distribution (Enterprise)
- Nodes and Oracles addition and removal (with provisioned identities) via bootstrapping / registration with Network Map
@ -76,19 +76,19 @@ Specifically, compatibility testing takes the following types of CorDapp-related
There are 3 failure scenarios to test for:
a) flows that hang (due to the expectation that a response is expected but never received)
a) flows that hang (due to en expected response never being received)
b) incorrect data types in `send` or `receive` calls: "Expected Type X but Received Type Y"
c) early termination: "Counterparty flow terminated early on the other side"
Inlined Flows are not versioned as they inherit the version of their parent `initiatingFlow` or `inittiatedFlow`.
Inlined Flows are not versioned as they inherit the version of their parent `initiatingFlow` or `initiatedFlow`.
There are 2 scenarios to consider:
a) Inlined flows that perform `send` and `receive` calling with other inlined flows
a) Inlined flows that perform `send` and `receive` calling with other inlined flows.
A change to the interface here must be considered a change to the parent flow interfaces.
b) Utility inlined flows that perform a local function (eg. query the vault).
b) Utility inlined flows that perform a local function (e.g., query the vault).
Flow Draining mode is used to ensure outstanding checkpointed flows are flushed before upgrading to a new flow version.
@ -96,7 +96,7 @@ Specifically, compatibility testing takes the following types of CorDapp-related
Two types of contract/state upgrade:
a) Implicit, using CZ Whitelisting of multiple CorDapp version (subsequently enforced by contract constraint logic)
a) Implicit, using Compatibility Zone (CZ) Whitelisting of multiple CorDapp version (subsequently enforced by contract constraint logic)
b) Explicit, by creating a special contract upgrade transaction and getting all participants of a state to sign it using
contract upgrade flows.

9
testing/qa/behave/compatibility/resources/features/compatibility/cordapp/cordapp-contract-versions.feature
View File

@ -13,7 +13,7 @@ Feature: Compatibility - CorDapp versions
Examples:
| Corda-Node-Version-X | Cordapp-Version-X | Cordapp-Version-Y |
| corda-3.0 | finance-V1-contract | finance-V2-contract |
| corda-3.0 | finance-V1-contract | finance-V2-contract |
Scenario Outline: Corda node can transact with another Corda node where each has a Cordapp version with same Contract verify but different State definition
Given a node A of version <Corda-Node-Version-X>
@ -26,7 +26,7 @@ Feature: Compatibility - CorDapp versions
Examples:
| Corda-Node-Version-X | Cordapp-Version-X | Cordapp-Version-Y |
| corda-3.0 | finance-V1-state | finance-V2-state |
| corda-3.0 | finance-V1-state | finance-V2-state |
Scenario Outline: Corda node can transact with another Corda node where each has a Cordapp version with same Contract verify but different State definition and custom schemas
Given a node A of version <Corda-Node-Version-X>
@ -39,4 +39,7 @@ Feature: Compatibility - CorDapp versions
Examples:
| Corda-Node-Version-X | Cordapp-Version-X | Cordapp-Version-Y |
| corda-3.0 | finance-V1-state-schema | finance-V2-state-schema |
| corda-3.0 | finance-V1-state-schema | finance-V2-state-schema |
Scenario Outline: Unhappy path scenarios to be added.
Examples: TODO

2
testing/qa/behave/compatibility/resources/features/compatibility/node/node-configuration.feature
View File

@ -29,7 +29,7 @@ Feature: Compatibility - Node configuration
| Corda-Node-Version-X |
| r3corda-3.0-DP3-RC01 |
Scenario Outline: R3 Corda node can transact with another Corda (OS) node where where node configuration is changed on both of the R3 Corda nodes
Scenario Outline: R3 Corda node can transact with another Corda (OS) node where node configuration is changed on both of the R3 Corda nodes
Given a node A of version <Corda-Node-Version-X>
And node A configuration is changed
And node A has the finance app installed

43
testing/qa/behave/compatibility/resources/features/compatibility/node/node-versions.feature
View File

@ -12,7 +12,6 @@ Feature: Compatibility - Node versions
Scenario Outline: Startup a Corda (OS) Node from Artifactory
Given a node PartyA of version <Corda-Node-Version>
And a node PartyB of version <Corda-Node-Version>
When the network is ready
Examples:
@ -39,8 +38,8 @@ Feature: Compatibility - Node versions
Scenario Outline: Startup a Corda (OS) Node with several Cordapps deployed.
Given a node PartyA of version <Corda-Node-Version>
# And node PartyA has app installed: net.corda:bank-of-corda-demo-corda:CORDA_VERSION
# And node PartyA has app installed: net.corda:trader-demo-corda:CORDA_VERSION
And node PartyA has app installed: net.corda:bank-of-corda-demo-corda:CORDA_VERSION
And node PartyA has app installed: net.corda:trader-demo-corda:CORDA_VERSION
When the network is ready
Then user can retrieve logging information for node A
And user can retrieve node identity information for node A
@ -48,41 +47,3 @@ Feature: Compatibility - Node versions
Examples:
| Corda-Node-Version |
| corda-3.0 |
Scenario Outline: Startup a Corda (OS) Node and issue some currency
Given a node PartyA of version <Corda-Node-Version>
And a nonvalidating notary Notary of version <Corda-Node-Version>
When the network is ready
Then node PartyA can issue 1000 <Currency>
Examples:
| Corda-Node-Version | Currency |
| corda-3.0 | GBP |
Scenario Outline: R3 Corda (Enterprise) Node can transact with Corda (OS) node, in a Corda OS configured network
Given a node PartyA of version <Corda-Node-Version>
And node PartyA has the finance app installed
And a node PartyB of version <R3-Corda-Node-Version>
And node PartyB has the finance app installed
And a nonvalidating notary Notary of version <Corda-Node-Version>
When the network is ready
Then node PartyA can issue 1000 <Currency>
And node PartyA can transfer 100 <Currency> to node B
Examples:
| Corda-Node-Version | R3-Corda-Node-Version | Currency |
| corda-3.0 | r3-master | GBP |
Scenario Outline: Corda (OS) Node can transact with R3 Corda (Enterprise) node, in an R3 Corda configured network.
Given a node PartyA of version <R3-Corda-Node-Version>
And node PartyA has the finance app installed
And a node PartyB of version <Corda-Node-Version>
And node PartyB has the finance app installed
And a nonvalidating notary Notary of version <R3-Corda-Node-Version>
When the network is ready
Then node PartyA can issue 1000 <Currency>
And node PartyA can transfer 100 <Currency> to node B
Examples:
| Corda-Node-Version | R3-Corda-Node-Version | Currency |
| corda-3.0 | r3-master | GBP |

5
testing/qa/behave/compatibility/resources/features/compatibility/notary/notary-change.feature
View File

@ -1,5 +1,5 @@
@compatibility @notary
Feature: Compatibility - Notary version change
Feature: Compatibility - Notary type change
To support an interoperable Corda network, a Corda node using a Notary type must have the ability to transact with another Corda node
using a different Notary type by changing Notarised states from one Notary type to another (by invoking notary change flow).
@ -29,3 +29,6 @@ Feature: Compatibility - Notary version change
| Corda-Node-Version | Notary-Type-A | Notary-Type-B |
| corda-3.0 | notary-validating | notary-non-validating |
Scenario Outline: Unhappy path scenarios to be added.
Examples: TODO

2
testing/qa/behave/compatibility/resources/features/compatibility/notary/notary-healthcheck.feature
View File

@ -5,7 +5,7 @@ Feature: Compatibility - Notary cluster member changes.
Scenario Outline: Corda (OS) health checker node can interact with R3 Corda RAFT notary cluster.
Given a node PartyA of version <Corda-Node-Version>
And node PartyA has app installed: <Cordapp-Name>
# And a 3 node validating RAFT notary cluster of version <R3-Corda-Node-Version>
And a 3 node validating RAFT notary cluster of version <R3-Corda-Node-Version>
When the network is ready
Then node PartyA can run <Cordapp-Name> <NumIterations> <SleepMillis>