-
Notifications
You must be signed in to change notification settings - Fork 130
Clique acceptance tests #290
Clique acceptance tests #290
Conversation
…jframe/pantheon into feature/NC-1524_clique_acceptance_tests
… more accurate clique getSigners test
# 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
.../src/test/java/tech/pegasys/pantheon/tests/acceptance/clique/CliqueMiningAcceptanceTest.java
Outdated
Show resolved
Hide resolved
.../java/tech/pegasys/pantheon/tests/acceptance/dsl/condition/blockchain/ExpectBeneficiary.java
Outdated
Show resolved
Hide resolved
.../java/tech/pegasys/pantheon/tests/acceptance/dsl/condition/blockchain/ExpectBlockNumber.java
Outdated
Show resolved
Hide resolved
...ests/src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/transaction/PantheonWeb3j.java
Show resolved
Hide resolved
...src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/transaction/CliqueTransactions.java
Outdated
Show resolved
Hide resolved
...c/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/transaction/clique/CliquePropose.java
Show resolved
Hide resolved
.../test/java/tech/pegasys/pantheon/tests/acceptance/clique/CliqueDiscardRpcAcceptanceTest.java
Outdated
Show resolved
Hide resolved
.../test/java/tech/pegasys/pantheon/tests/acceptance/clique/CliqueDiscardRpcAcceptanceTest.java
Show resolved
Hide resolved
...sts/src/test/java/tech/pegasys/pantheon/tests/acceptance/clique/CliqueGetSignersRpcTest.java
Show resolved
Hide resolved
.../src/test/java/tech/pegasys/pantheon/tests/acceptance/clique/CliqueMiningAcceptanceTest.java
Show resolved
Hide resolved
.../test/java/tech/pegasys/pantheon/tests/acceptance/clique/CliqueProposeRpcAcceptanceTest.java
Show resolved
Hide resolved
@@ -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) { |
There was a problem hiding this comment.
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.
…jframe/pantheon into feature/nc-1524_clique_acceptance_tests
try { | ||
Thread.sleep(INITIAL_WAIT); | ||
final BigInteger lastBlock = node.execute(eth.blockNumber()); | ||
Thread.sleep(WAIT); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
# Conflicts: # acceptance-tests/build.gradle
.../test/java/tech/pegasys/pantheon/tests/acceptance/clique/CliqueDiscardRpcAcceptanceTest.java
Outdated
Show resolved
Hide resolved
.../test/java/tech/pegasys/pantheon/tests/acceptance/clique/CliqueDiscardRpcAcceptanceTest.java
Show resolved
Hide resolved
cluster.verify(clique.validatorsAtBlockEqual("0x1", initialNodes)); | ||
|
||
minerNode1.waitUntil(wait.chainHeadHasProgressed(minerNode1, 1)); | ||
cluster.verify(clique.validatorsAtBlockEqual("0x3", allNodes)); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…are potential miners
# Conflicts: # acceptance-tests/src/test/java/tech/pegasys/pantheon/tests/acceptance/dsl/AcceptanceTestBase.java
There was a problem hiding this 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.
PR description
Adds acceptance tests for the Clique consensus mechanism.
Fixed Issue(s)