Skip to content
This repository has been archived by the owner on Sep 26, 2019. It is now read-only.

Clique acceptance tests #290

Merged

Conversation

jframe
Copy link
Contributor

@jframe jframe commented Nov 21, 2018

PR description

Adds acceptance tests for the Clique consensus mechanism.

Fixed Issue(s)

jframe added 30 commits October 16, 2018 16:06
…jframe/pantheon into feature/NC-1524_clique_acceptance_tests
# Conflicts:
#	acceptance-tests/src/test/java/tech/pegasys/pantheon/tests/acceptance/CreateAccountAcceptanceTest.java
#	acceptance-tests/src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/AcceptanceTestBase.java
#	acceptance-tests/src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/node/Eth.java
#	acceptance-tests/src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/node/Node.java
#	acceptance-tests/src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/node/PantheonNode.java
#	acceptance-tests/src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/node/ThreadPantheonNodeRunner.java
#	acceptance-tests/src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/transaction/web3/Web3Sha3Transaction.java
#	pantheon/src/main/java/tech/pegasys/pantheon/cli/EthNetworkConfig.java
@@ -110,20 +107,10 @@ public BytesValue getVanityData() {
return validators;
}

public static String createGenesisExtraDataString(final List<PrivateKey> privKeys) {
final List<Address> validators = convertPrivKeysToAddresses(privKeys);
public static String createGenesisExtraDataString(final List<Address> validators) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the real world (not acceptance test) - we would often be provided with either:
PrivateKey, or Public Key (or Address I guess) - it'd be great to have the ability to convert from any of these three things, into a genesis ExtraData String.
Happy for the priv --> pub --> address utility to live somewhere else, but we should try and keep it methinks.

try {
Thread.sleep(INITIAL_WAIT);
final BigInteger lastBlock = node.execute(eth.blockNumber());
Thread.sleep(WAIT);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be using a waiter that we expect to fail instead of a hard coded sleep - that way if a new block is published it fails immediately. It's a small thing but not having to wait 15 seconds every time makes a big difference if you're trying to work out why the test is failing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah not nice, but was simple. I've ended up changing it fail immediately if we get a new block.

cluster.verify(clique.validatorsAtBlockEqual("0x1", initialNodes));

minerNode1.waitUntil(wait.chainHeadHasProgressed(minerNode1, 1));
cluster.verify(clique.validatorsAtBlockEqual("0x3", allNodes));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this work with 0x2? or does it have to be 3?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are already at block 1 when vote in the new validator, so it is working after 2 blocks have progressed.

minerNode1.execute(transactions.createTransfer(sender, 50));
cluster.verify(sender.balanceEquals(50));

minerNode2.execute(transactions.createIncrementalTransfers(sender, receiver, 1));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I suspect there's a risk that you haven't actually mined separate blocks - can the test be updated to ensure the transactions are spread across blocks?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The transfers are being done from different nodes so there should be multiple blocks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Transactions are communicated between nodes. They're only guaranteed to be in different blocks if you wait for their effects to be applied before sending the next transaction. So:

minerNode1.execute(transactions.createTransfer(sender, 50));
    cluster.verify(sender.balanceEquals(50));

Must be in one block and any transaction sent after that must be in a different block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah true, fortunately am following that pattern of during the transfer and then waiting for the effects the applied.

So this what is being done atm:
` minerNode1.execute(transactions.createTransfer(sender, 50));
cluster.verify(sender.balanceEquals(50));

minerNode2.execute(transactions.createIncrementalTransfers(sender, receiver, 1));
cluster.verify(receiver.balanceEquals(1));

minerNode3.execute(transactions.createIncrementalTransfers(sender, receiver, 2));
cluster.verify(receiver.balanceEquals(3));`

So I'm expecting that at least 3 blocks will be created by doing this.

# Conflicts:
#	acceptance-tests/src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/AcceptanceTestBase.java
Copy link
Contributor

@rain-on rain-on left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to write some tests around progressing when a validator has stopped, and also check if signer's of the blocks actually iterates.

@jframe jframe merged commit ab744a9 into PegaSysEng:master Nov 29, 2018
@jframe jframe deleted the feature/nc-1524_clique_acceptance_tests branch December 6, 2018 00:26
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants