Make the fixturenet eth tests more robust #581

New Issue

dboreham · 2023-10-13T13:52:26Z

dboreham commented

2023-10-13 13:52:26 +00:00

Currently the fixturenet-{plugeth-}eth tests discriminate the result by mean of a check that the chain block height advances over a time interval. The idea being that if the chain isn't working, there either won't be a block height, or it will be stuck at zero (or possibly some other number close to zero).

Problem is that the current code for making this determination is sensitive to timing. It just waits a fixed number of seconds. On a slow test runner this time can be too short. But we don't want the test to take forever to run on a fast machine.

It would be better if the block height check was done in a polling loop -- check for a height, if none found wait a bit then check again. Keep doing that for some fairly long time. Then same thing for checking for the second block height. Using this approach the test would adapt to the speed of the runner and only take a long time on a slow machine, or in the event the test is going to fail (because the block height never advances).

Currently the fixturenet-{plugeth-}eth tests discriminate the result by mean of a check that the chain block height advances over a time interval. The idea being that if the chain isn't working, there either won't be a block height, or it will be stuck at zero (or possibly some other number close to zero). Problem is that the [current code](https://github.com/cerc-io/stack-orchestrator/blob/main/tests/fixturenet-eth/run-test.sh#L29) for making this determination is sensitive to timing. It just waits a fixed number of seconds. On a slow test runner this time can be too short. But we don't want the test to take forever to run on a fast machine. It would be better if the block height check was done in a polling loop -- check for a height, if none found wait a bit then check again. Keep doing that for some fairly long time. Then same thing for checking for the second block height. Using this approach the test would adapt to the speed of the runner and only take a long time on a slow machine, or in the event the test is going to fail (because the block height never advances).

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/stack-orchestrator#581