Skip to content
This repository has been archived by the owner on May 23, 2023. It is now read-only.

Test Scenarios

Sven Ehlert edited this page Feb 25, 2015 · 17 revisions

More detailed infos about test scenarios. (for reference)

List of all scenarios, planned and done

Basic connection scenario

This is the base scenario of system testing.

Client Types: Go, C++, Python

Results: 
Go [partially tested]
C++ [not tested]
Python [not tested]

Theoretical Scenario - Implementation plan

v1 - done

  • A clean environment is created, where no previous blockchain exists.
  • A Go bootstrap node is deployed.
  • Afterwards 5 Go clients are started simultaneously, connecting to bootstrap node.
  • wait for max 30 secs
  • evaluate that
    • each client is started
    • each client was connected to the bootstrap node
    • each client is connected to all other 4 clients
    • a client is not connected to itself

necessary logging events: starting, p2p.connected, p2p.disconnected see Log Events

v2 - done

  • same as above, but launch 200 Go clients.
  • wait max 30 secs
  • evaluate that
    • each client is started
    • each client was connected to the bootstrap node
    • each client is connected at least to (-maxpeers) other clients
    • a client is not connected to itself

v3 (as soon as cpp has minimal logging implemented)

  • same as v2, but only use cpp implementation, both for bootstrap and clients

v4

  • A clean environment is created, where no previous blockchain exists.
  • A Go bootstrap node is deployed.
  • Afterwards 100 Go and 100 cpp clients are started simultaneously, connecting to bootstrap node.
  • wait max 30 secs
  • evaluate that
    • each client is started
    • each client was connected to the bootstrap node
    • each client is connected at least to xx other clients
    • at least 1 Go client is connected to a cpp client and vice versa
    • no client is not connected to itself

Well-formed network scenario (TDB, not yet finalized)

  • start 200 clients over time, 20 sec after each client
  • wait 20 secs after last client
  • every node is connected to maxpeer nodes plus each each node's connections are the optimal distance connections.

Basic Consensus Scenario

Theoretical Scenario

x clients plus one bootstrapping nodes are deployed. Each client is fresh to the network, e.g. hasn't participated on any blockchain before. Each client will get its peers from the bootstrapping node. Each client starts and stops mining randomly. When the scenario stops, all clients have found consensus.

Implementation

Implemented via https://github.com/ethereum/system-testing/blob/master/scenarios/scenario_chain_consensus.py.

Currently works with python client. To support other clients, they need to support the following structured logging messages.

necessary logging: eth.chain.new_head see Log Events

Basic transaction scenario

Theoretical scenario

starts one client
        let it mine some ether
    start all clients
    create tx client_0 > client_1
    send tx to one client
    check tx propagation time < X (much smaller than blocktime)
    check consensus

Implementation

implemented in https://github.com/ethereum/system-testing/blob/master/scenarios/scenario_tx_propagation.py

This uses RPC to send transactions. TODO check JSON-RPC usability

Log on new tx received: eth.tx.new_tx see [Log Events]https://github.com/ethereum/system-testing/wiki/Log-Events#definition)

Further scenarios

new scenarios will need additional structured log messages to be implemented.