Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finish state tests intro #1114

Merged
merged 22 commits into from
May 27, 2019
Merged
Show file tree
Hide file tree
Changes from 18 commits
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
6cd681e
update docs on operation testing
protolambda May 23, 2019
e218c4f
update operations readme, fix wording
protolambda May 23, 2019
754d972
implement epoch processing test-gen, bugfix tests
protolambda May 23, 2019
c11f963
cleanup generator code, use helper pkg to load and generate test case…
protolambda May 23, 2019
e1b04f4
sanity tests generator
protolambda May 23, 2019
3500bde
only sign in test_double_late_crosslink when necessary
djrtwo May 23, 2019
f0c9e7a
ignore just the one crosslinks case that is incompatible with mainnet
protolambda May 23, 2019
1bbab9a
more direct in what is happening in test utils
protolambda May 23, 2019
21c48b5
move sanity tests, separate slot tests
protolambda May 23, 2019
f98a8d5
update epoch processing tests to conform to processing pattern, add d…
protolambda May 23, 2019
902059d
fix operations readme
protolambda May 23, 2019
4ccd304
docs for sanity tests
protolambda May 23, 2019
57dd9fc
fix syntax
protolambda May 23, 2019
f52b228
Update specs/test_formats/operations/README.md
protolambda May 24, 2019
4690bcf
Update specs/test_formats/operations/README.md
protolambda May 24, 2019
f2e3cd0
Update test_libs/pyspec/eth2spec/test/epoch_processing/test_process_c…
protolambda May 24, 2019
73f0f74
run process yield-from test pattern
protolambda May 24, 2019
321baf7
fix missing imports from earlier code suggestion
protolambda May 24, 2019
b6b5787
Update specs/test_formats/epoch_processing/README.md
protolambda May 24, 2019
b12031b
not signed by default
protolambda May 24, 2019
e9a01a2
epoch processing formatting
protolambda May 24, 2019
8d420c0
fix prestate for process registry updates
djrtwo May 27, 2019
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
34 changes: 34 additions & 0 deletions specs/test_formats/epoch_processing/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
# Epoch processing tests

The different epoch sub-transitions are tested individually with test handlers.
The format is similar to block-processing state-transition tests.
There is no "change" factor however, the transitions are a pure functions with just the pre-state as input.
protolambda marked this conversation as resolved.
Show resolved Hide resolved
Hence, the format is shared between each test-handler. (See test condition documentation on how to run the tests.)

## Test case format

```yaml
description: string -- description of test case, purely for debugging purposes
bls_required: bool -- optional, true if the test validity is strictly dependent on BLS being ON. False otherwise.
bls_ignored: bool -- optional, true if the test validity is strictly dependent on BLS being OFF. False otherwise.
pre: BeaconState -- state before running the sub-transition
post: BeaconState -- state after applying the epoch sub-transition.
```

Note: if both `bls_required` and `bls_ignored` are false (or simply not included),
then the test consumer can freely choose to run with BLS ON or OFF.
One may choose for OFF for performance reasons during repeated testing. Otherwise it is recommended to run with BLS ON.

## Condition

A handler of the `epoch_processing` test-runner should process these cases,
calling the corresponding processing implementation.

Sub-transitions:

| *`sub-transition-name`* | *`processing call`* |
|-------------------------|-----------------------------------|
| `crosslinks` | `process_crosslinks(state)` |
| `registry_updates` | `process_registry_updates(state)` |

The resulting state should match the expected `post` state.
36 changes: 33 additions & 3 deletions specs/test_formats/operations/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,39 @@

The different kinds of operations ("transactions") are tested individually with test handlers.

The tested operation kinds are:
- [`deposits`](./deposits.md)
- More tests are work-in-progress.
## Test case format

```yaml
description: string -- description of test case, purely for debugging purposes
bls_required: bool -- optional, true if the test validity is strictly dependent on BLS being ON. False otherwise.
bls_ignored: bool -- optional, true if the test validity is strictly dependent on BLS being OFF. False otherwise.
pre: BeaconState -- state before applying the operation
<operation-name>: <operation-object> -- the YAML encoded operation, e.g. a "ProposerSlashing", or "Deposit".
post: BeaconState -- state after applying the operation. No value if operation processing is aborted.
```

Note: if both `bls_required` and `bls_ignored` are false (or simply not included),
then the test consumer can freely choose to run with BLS ON or OFF.
One may choose for OFF for performance reasons during repeated testing. Otherwise it is recommended to run with BLS ON.

## Condition

A handler of the `operations` test-runner should process these cases,
calling the corresponding processing implementation.

Operations:

| *`operation-name`* | *`operation-object`* | *`input name`* | *`processing call`* |
|-------------------------|----------------------|----------------------|--------------------------------------------------------|
| `attestation` | `Attestation` | `attestation` | `process_attestation(state, attestation)` |
| `attester_slashing` | `AttesterSlashing` | `attester_slashing` | `process_attester_slashing(state, attester_slashing)` |
| `block_header` | `Block` | `block` | `process_block_header(state, block)` |
| `deposit` | `Deposit` | `deposit` | `process_deposit(state, deposit)` |
| `proposer_slashing` | `ProposerSlashing` | `proposer_slashing` | `process_proposer_slashing(state, proposer_slashing)` |
| `transfer` | `Transfer` | `transfer` | `process_transfer(state, transfer)` |
| `voluntary_exit` | `VoluntaryExit` | `voluntary_exit` | `process_voluntary_exit(state, voluntary_exit)` |

Note that `block_header` is not strictly an operation (and is a full `Block`), but processed in the same manner, and hence included here.

The resulting state should match the expected `post` state, or if the `post` state is left blank,
the handler should reject the input operation as invalid.
18 changes: 0 additions & 18 deletions specs/test_formats/operations/deposits.md

This file was deleted.

7 changes: 7 additions & 0 deletions specs/test_formats/sanity/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# Sanity tests
protolambda marked this conversation as resolved.
Show resolved Hide resolved

The aim of the sanity tests is to set a base-line on what really needs to pass, i.e. the essentials.

There are two handlers, documented individually:
- [`slots`](./slots.md): transitions of one or more slots (and epoch transitions within)
- [`blocks`](./blocks.md): transitions triggered by one or more blocks
19 changes: 19 additions & 0 deletions specs/test_formats/sanity/blocks.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
# Sanity blocks testing

Sanity tests to cover a series of one or more blocks being processed, aiming to cover common changes.

## Test case format

```yaml
description: string -- description of test case, purely for debugging purposes
bls_required: bool -- optional, true if the test validity is strictly dependent on BLS being ON. False otherwise.
bls_ignored: bool -- optional, true if the test validity is strictly dependent on BLS being OFF. False otherwise.
pre: BeaconState -- state before running through the transitions triggered by the blocks.
blocks: [BeaconBlock] -- blocks to process, in given order, following the main transition function (i.e. process slot and epoch transitions in between blocks as normal)
post: BeaconState -- state after applying all the transitions triggered by the blocks.
```

## Condition

The resulting state should match the expected `post` state, or if the `post` state is left blank,
the handler should reject the series of blocks as invalid.
24 changes: 24 additions & 0 deletions specs/test_formats/sanity/slots.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# Sanity slots testing

Sanity tests to cover a series of one or more empty-slot transitions being processed, aiming to cover common changes.

## Test case format

```yaml
description: string -- description of test case, purely for debugging purposes
bls_required: bool -- optional, true if the test validity is strictly dependent on BLS being ON. False otherwise.
bls_ignored: bool -- optional, true if the test validity is strictly dependent on BLS being OFF. False otherwise.
pre: BeaconState -- state before running through the transitions.
slots: N -- amount of slots to process, N being a positive numer.
post: BeaconState -- state after applying all the transitions.
```

The transition with pure time, no blocks, is known as `state_transition_to(state, slot)` in the spec.
This runs state-caching (pure slot transition) and epoch processing (every E slots).

To process the data, call `state_transition_to(pre, pre.slot + N)`. And see if `pre` mutated into the equivalent of `post`.


## Condition

The resulting state should match the expected `post` state.
11 changes: 11 additions & 0 deletions test_generators/epoch_processing/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# Epoch processing

Epoch processing covers the sub-transitions during an epoch change.

An epoch-processing test-runner can consume these sub-transition test-suites,
and handle different kinds of epoch sub-transitions by processing the cases using the specified test handler.

Information on the format of the tests can be found in the [epoch-processing test formats documentation](../../specs/test_formats/epoch_processing/README.md).



38 changes: 38 additions & 0 deletions test_generators/epoch_processing/main.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
from typing import Callable, Iterable

from eth2spec.test.epoch_processing import (
test_process_crosslinks,
test_process_registry_updates
)

from gen_base import gen_runner, gen_suite, gen_typing
from gen_from_tests.gen import generate_from_tests
from preset_loader import loader
from eth2spec.phase0 import spec


def create_suite(transition_name: str, config_name: str, get_cases: Callable[[], Iterable[gen_typing.TestCase]]) \
-> Callable[[str], gen_typing.TestSuiteOutput]:
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick: IMO avoid \ here

def create_suite(
        transition_name: str,
        config_name: str,
        get_cases: Callable[[],
        Iterable[gen_typing.TestCase]]) -> Callable[[str], gen_typing.TestSuiteOutput]:

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

My IDE gives a PEP8 warning with that suggestion.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

And formatter adds 20 spaces of indentation to the last line of that suggestion, and then it's happy... I'd rather keep it as-is.

def suite_definition(configs_path: str) -> gen_typing.TestSuiteOutput:
presets = loader.load_presets(configs_path, config_name)
spec.apply_constants_preset(presets)

return ("%s_%s" % (transition_name, config_name), transition_name, gen_suite.render_suite(
title="%s epoch processing" % transition_name,
summary="Test suite for %s type epoch processing" % transition_name,
forks_timeline="testing",
forks=["phase0"],
config=config_name,
runner="epoch_processing",
handler=transition_name,
test_cases=get_cases()))
return suite_definition


if __name__ == "__main__":
gen_runner.run_generator("epoch_processing", [
create_suite('crosslinks', 'minimal', lambda: generate_from_tests(test_process_crosslinks)),
create_suite('crosslinks', 'mainnet', lambda: generate_from_tests(test_process_crosslinks)),
create_suite('registry_updates', 'minimal', lambda: generate_from_tests(test_process_registry_updates)),
create_suite('registry_updates', 'mainnet', lambda: generate_from_tests(test_process_registry_updates)),
])
4 changes: 4 additions & 0 deletions test_generators/epoch_processing/requirements.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
eth-utils==1.6.0
../../test_libs/gen_helpers
../../test_libs/config_helpers
../../test_libs/pyspec
1 change: 0 additions & 1 deletion test_generators/operations/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,6 @@
Operations (or "transactions" in previous spec iterations),
are atomic changes to the state, introduced by embedding in blocks.

This generator provides a series of test suites, divided into handler, for each operation type.
An operation test-runner can consume these operation test-suites,
and handle different kinds of operations by processing the cases using the specified test handler.

Expand Down
26 changes: 24 additions & 2 deletions test_generators/operations/main.py
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
from typing import Callable, Iterable

from eth2spec.test.block_processing import (
test_process_attestation,
test_process_attester_slashing,
Expand All @@ -8,9 +10,29 @@
test_process_voluntary_exit
)

from gen_base import gen_runner
from gen_base import gen_runner, gen_suite, gen_typing
from gen_from_tests.gen import generate_from_tests
from preset_loader import loader
from eth2spec.phase0 import spec


def create_suite(operation_name: str, config_name: str, get_cases: Callable[[], Iterable[gen_typing.TestCase]]) \
-> Callable[[str], gen_typing.TestSuiteOutput]:
Copy link
Contributor

Choose a reason for hiding this comment

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

ditto

def create_suite(
        transition_name: str,
        config_name: str,
        get_cases: Callable[[],
        Iterable[gen_typing.TestCase]]) -> Callable[[str], gen_typing.TestSuiteOutput]:

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

See above comment

def suite_definition(configs_path: str) -> gen_typing.TestSuiteOutput:
presets = loader.load_presets(configs_path, config_name)
spec.apply_constants_preset(presets)

return ("%s_%s" % (operation_name, config_name), operation_name, gen_suite.render_suite(
title="%s operation" % operation_name,
summary="Test suite for %s type operation processing" % operation_name,
forks_timeline="testing",
forks=["phase0"],
config=config_name,
runner="operations",
handler=operation_name,
test_cases=get_cases()))
return suite_definition

from suite_creator import generate_from_tests, create_suite

if __name__ == "__main__":
gen_runner.run_generator("operations", [
Expand Down
39 changes: 0 additions & 39 deletions test_generators/operations/suite_creator.py

This file was deleted.

8 changes: 8 additions & 0 deletions test_generators/sanity/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Sanity tests

Sanity tests cover regular state-transitions in a common block-list format, to ensure the basics work.

Information on the format of the tests can be found in the [sanity test formats documentation](../../specs/test_formats/sanity/README.md).



35 changes: 35 additions & 0 deletions test_generators/sanity/main.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
from typing import Callable, Iterable

from eth2spec.test.sanity import test_blocks, test_slots

from gen_base import gen_runner, gen_suite, gen_typing
from gen_from_tests.gen import generate_from_tests
from preset_loader import loader
from eth2spec.phase0 import spec


def create_suite(handler_name: str, config_name: str, get_cases: Callable[[], Iterable[gen_typing.TestCase]]) \
-> Callable[[str], gen_typing.TestSuiteOutput]:
def suite_definition(configs_path: str) -> gen_typing.TestSuiteOutput:
presets = loader.load_presets(configs_path, config_name)
spec.apply_constants_preset(presets)

return ("%sanity_s_%s" % (handler_name, config_name), handler_name, gen_suite.render_suite(
title="sanity testing",
summary="Sanity test suite, %s type, generated from pytests" % handler_name,
forks_timeline="testing",
forks=["phase0"],
config=config_name,
runner="sanity",
handler=handler_name,
test_cases=get_cases()))
return suite_definition


if __name__ == "__main__":
gen_runner.run_generator("sanity", [
create_suite('blocks', 'minimal', lambda: generate_from_tests(test_blocks)),
create_suite('blocks', 'mainnet', lambda: generate_from_tests(test_blocks)),
create_suite('slots', 'minimal', lambda: generate_from_tests(test_slots)),
create_suite('slots', 'mainnet', lambda: generate_from_tests(test_slots)),
protolambda marked this conversation as resolved.
Show resolved Hide resolved
])
4 changes: 4 additions & 0 deletions test_generators/sanity/requirements.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
eth-utils==1.6.0
../../test_libs/gen_helpers
../../test_libs/config_helpers
../../test_libs/pyspec
Empty file.
25 changes: 25 additions & 0 deletions test_libs/gen_helpers/gen_from_tests/gen.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
from inspect import getmembers, isfunction

def generate_from_tests(src, bls_active=True):
"""
Generate a list of test cases by running tests from the given src in generator-mode.
:param src: to retrieve tests from (discovered using inspect.getmembers)
:param bls_active: optional, to override BLS switch preference. Defaults to True.
:return: the list of test cases.
"""
fn_names = [
name for (name, _) in getmembers(src, isfunction)
if name.startswith('test_')
]
out = []
print("generating test vectors from tests source: %s" % src.__name__)
for name in fn_names:
tfn = getattr(src, name)
try:
test_case = tfn(generator_mode=True, bls_active=bls_active)
# If no test case data is returned, the test is ignored.
if test_case is not None:
out.append(test_case)
except AssertionError:
print("ERROR: failed to generate vector from test: %s (src: %s)" % (name, src.__name__))
return out
2 changes: 1 addition & 1 deletion test_libs/gen_helpers/setup.py
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

setup(
name='gen_helpers',
packages=['gen_base'],
packages=['gen_base', 'gen_from_tests'],
install_requires=[
"ruamel.yaml==0.15.96",
"eth-utils==1.6.0"
Expand Down