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

Better test descriptions and tool to generate test list #441

Open
axic opened this issue Mar 27, 2018 · 6 comments
Open

Better test descriptions and tool to generate test list #441

axic opened this issue Mar 27, 2018 · 6 comments

Comments

@axic
Copy link
Member

axic commented Mar 27, 2018

The state tests have a _info section with a comment field, however that rarely contains anything.

It would be nice if there would be a mandatory description field explaining what the test supposed to do and a tool run on the CI would actually generate a table of test name + description + path 😉

@axic axic changed the title Better test descriptions Better test descriptions and tool to generate test list Mar 27, 2018
@axic
Copy link
Member Author

axic commented Mar 27, 2018

Example:

name description path
codesizeOOGInvalidSize Create oversized (400000 bytes) contract via a creation transaction stCodeSizeLimit/codesizeOOGInvalidSizeFiller.json

@holgerd77
Copy link
Contributor

holgerd77 commented Apr 6, 2018

I would very much support this and go as far to suggest that you should make this one of your projects with strategic priority (whatever this means, sounded great 😄 ).

This ethereum/tests repository is wonderful and one of technical parts of the Ethereum ecosystem I admire the most for its thought-throughness and clarity. And this was probably the starting point for various clients to be implemented.

In everyday live this excitement cools down a bit 😺 since I have already spent countless hours figuring out the purpose of test cases (especially if one is not a fluent LLL reader) to get a grip where to start debugging.

A simple comment on every test case would be extremely valuable here. I know this is not the most rewarding kind of work, but if this is done in some various not-too-extensive stages this should be manageable.

@axic
Copy link
Member Author

axic commented Apr 26, 2018

Related: #340.

@ehildenb
Copy link
Contributor

#461 is now checking that the _info block with the fields source and sourceHash are present. @zixuanzh can look into supporting the remaining fields and fixing tests that do not have them.

Also, since the script ./test.py is now asserting that those fields exist, we can have a reliable way to list this information in the same tool, using ./test.py info instead of ./test.py list.

@winsvega
Copy link
Collaborator

winsvega commented May 7, 2021

that would be a great research work. I think with the coverage analizer we can run and see which tests are covering what exactly.
and would be nice to have a quiery engine for that

@winsvega
Copy link
Collaborator

Since yul tests there are many description comments in the yul file itself outside of json fields. The tests classification remains open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants