-
Notifications
You must be signed in to change notification settings - Fork 998
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
Spectest decorator #1052
Spectest decorator #1052
Conversation
ported all remaining tests. |
whoops on the extra array nesting. nice catch |
…soft-import, update readme and makefile
Tests are running, and I got block-operation generators to work based on the same tests 🎉 |
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 general really happy with it. The main thing missing is documenting usage, but that can come once we do another pass and add other test types.
Just a few very minor comments.
We should cut a v0.6.1-t0
release to master and backport this into dev
Co-Authored-By: Danny Ryan <[email protected]>
72bc73a
to
8570584
Compare
Cleaned up PR suggestion commits |
Co-Authored-By: jannikluhn <[email protected]>
3189cf0 includes the new edge cases presented in #1010, in a more concise form, as part of the unified spec-tests. Thanks @jannikluhn. Hope to write many more spectests in this format with the other testers, sorry about the delay getting the tests in because of this PR. |
Co-Authored-By: Dmitry S <[email protected]>
merging. |
Since the pytests share a lot of "edge case" setups with test-generation, I'm looking to unify these tests with the generator code, i.e. not duplicate testing work.
To achieve this, a few things have to be changed:
context.py
/utils.py
:with_args
(generalized) andwith_state
(built on top of generalized version, provides fresh genesis state).yield from
is a blessing) and faster (less, if not none, deep-copies)The new format:
We have a new decorator for tests:
@spectest(description='very informative')
(description is optional)This decorator enables you to:
generator_mode
param, whenTrue
it makes the test function collect yielded data into a dict, incl. description, and return it.generator_mode
(default).Example test:
Note that in some cases, some of it can be generalized with a local helper function, and then you just call
yield from run_processing_foobar(state, operation)
or similar. See POC attestations test update.And, you can call the test to create a test-case vector:
Note that values yielded in generator mode are encoded before continuing in the function, so there's no deep-copy necessary: after encoding the original containers may mutate.
This also speeds up the normal test-runs, as values are not collected/encoded, nor deep-copied, so you get the minimal amount of object instances / memory allocation / etc.
Some syntax sugar
99% of the pytests look like this:
To make this shorter, we define a
@spec_state_test
that composes these two generators. It's literally a state-spec-test!For anyone interested in previous iterations of the edge-case unification idea, here they are: https://notes.ethereum.org/5N7MrvOESrKK3AIHYYvYww#
The important pivot made here is that we do not separate the edge-cases from testing, nor do we reference the processing function, and make the decorator run the behavior. This enables more freedom in testing, yet it is powerful enough to create test-vectors cleanly from the existing pytest work.
Next steps: