fe313951ea
As reported in [CORDA-1609](https://r3-cev.atlassian.net/browse/CORDA-1609),
`CordaRPCClientConfiguration.default` is not accessible from Java since
`default` is a reserved keyword.
As part of the refactor made in #2831, `CordaRPCClientConfiguration` went
from being a data class to an interface with a backing implementation of
type `CordaRPCClientConfigurationImpl`.
This resulted in Java users having to rewrite code that was on the form:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.DEFAULT
);
```
to something like this:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.Companion.default()
);
```
However, this does not work. The user would get a compilation error because
`default` is a reserved keyword in Java.
Since `CordaRPCClientConfiguration` has been made an interface, there is no
easy way of introducing a static final field on the interface from Kotlin.
Consequently, I've changed this back to using a `class` with a static field
named `DEFAULT` instead of the static method `default()`.
It should be noted that `default()` / `DEFAULT` is currently only used
internally to pass in default values in `CordaRPCClient.kt` and
`CordaRPCClientUtils.kt`. That said, it is exposed as part of our API
surface and consequently shouldn't be broken.
The latter means that in the above example, the user would actually not
have to provide the parameter at all:
```java
final CordaRPCClient client = new CordaRPCClient(nodeAddress);
```
As can be seen from the definition of `CordaRPCClient`:
```kotlin
class CordaRPCClient private constructor(...) {
@JvmOverloads
constructor(
hostAndPort: NetworkHostAndPort,
configuration: CordaRPCClientConfiguration = CordaRPCClientConfiguration.DEFAULT
) : this(hostAndPort, configuration, null)
```
The mentioned [refactor](
|
||
|---|---|---|
| .. | ||
| deps | ||
| src | ||
| build.gradle | ||
| prepare.sh | ||
| README.md | ||
Introduction
This project illustrates how one can use Cucumber / BDD to drive and test homogeneous and heterogeneous Corda networks on a local machine. The framework has built-in support for Dockerised node dependencies so that you easily can spin up a Corda node locally that, for instance, uses a 3rd party database provider such as Postgres.
Structure
The project is split into three pieces:
-
Testing Library (main) - This library contains auxiliary functions that help in configuring and bootstrapping Corda networks on a local machine. The purpose of the library is to aid in black-box testing and automation.
-
Unit Tests (test) - These are various tests for the library described above. Note that there's only limited coverage for now.
-
BDD Framework (scenario) - This module shows how to use BDD-style frameworks to control the testing of Corda networks; more specifically, using Cucumber.
Setup
To get started, please follow the instructions below:
-
Go up to the root directory and build the capsule JAR.
$ cd ../../ $ ./gradlew install -
Come back to this folder and run:
$ cd experimental/behave $ ./prepare.sh
This script will download necessary database drivers and set up the dependencies directory with copies of the Corda fat-JAR and the network bootstrapping tool.
Selective Runs
If you only want to run tests of a specific tag, you can append the following parameter to the Gradle command:
$ ../../gradlew scenario -Ptags="@cash"
# or
$ ../../gradlew scenario -Ptags="@cash,@logging"