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

Add tap-spec option to npm test commands for mocha style reporting #363

Merged
merged 6 commits into from
Oct 15, 2018

Conversation

danjm
Copy link
Contributor

@danjm danjm commented Sep 26, 2018

This PR will allow us to see more details in the reports at the end of our test runs. In particular, we can now see a list of failed tests after all tests have run. This is done by adding a :tap-spec flag to any 'npm run test-name' command. The resulting output is formatted like the output of mocha's reporter. This is done using https://github.com/scottcorgan/tap-spec

For example, the current report from running npm run testBlockchainValid:tap-spec is

screenshot from 2018-09-26 16-00-44

Copy link
Member

@holgerd77 holgerd77 left a comment

Choose a reason for hiding this comment

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

Thanks for the PR, to use this tool makes a lot of sense and should be super-useful. In the current form this bloats the list of scripts too much and introduces duplicity. Is there any reason not to add this directly to the original script commands. Otherwise I would prefer a lower-level solution like adding these to the dependencies (I am generally cautious on introducing new dependencies, this should be worth it though), and then just point in the README test section to the new possibility for summarized reports by adding the tap-spec pipe.

@axic
Copy link
Member

axic commented Sep 27, 2018

The main point of tap is that the output can be streamed through formatters. One could just run npm run testAPI | tap-spec.

@holgerd77
Copy link
Member

Is tap-spec then emitting the same uncondensed output again? Then there should be nothing hindering to add this to the original commands, should it?

@axic
Copy link
Member

axic commented Sep 27, 2018

No, tap-spec is doing the formatting already. One cannot run any other formatter on it afterwards.

@holgerd77
Copy link
Member

@danjm I think we should then just stick to the low-level dependency + README version.

@danjm
Copy link
Contributor Author

danjm commented Sep 28, 2018

@holgerd77 I made a significant change that attempts to incorporate your feedback while still adding an npm script to help developers.

The problem with just adding a dependency is that developers will have to specify the path to the executable via node_modules/.bin/. npm run testAPI | tap-spec will only work if tap-spec is installed globally.

If we want to keep things really simple we could just put a note in the README about globally installing reporters, a link to some recommended reporters and an example of piping to it. This would avoid installing another dependency. I think that is a fine approach.

Alternatively, I just pushed commit ffe689a

It only adds one npm script, which can receive a script name or path as an argument. It pipes to tap-spec by default, but can receive an argument that specifies a different reporter. It does this via a node script that I added to a new scripts/ directory.

The additions made to the README in the commit explain the usage in more detail, with examples.

Copy link
Member

@holgerd77 holgerd77 left a comment

Choose a reason for hiding this comment

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

Hi Dan, I am generally ok with this approach, thanks for the rework!

Should we also add this to the CircleCI testState... commands and would the feedback mechanism for success/failure back to GitHub still work (cc @axic, @jwasinger)? I would like this a lot to always have a comprised test report at the end of a test run, this "not ok" full-text search is really not optimal! 😄

package.json Outdated
@@ -17,13 +17,14 @@
"testBlockchain": "npm run build:dist && node --stack-size=1500 ./tests/tester -b --dist --excludeDir='GeneralStateTests'",
"testBlockchainGeneralStateTests": "npm run build:dist && node --stack-size=1500 ./tests/tester -b --dist --dir='GeneralStateTests'",
"testBlockchainBlockGasLimit": "npm run build:dist && node --stack-size=1500 ./tests/tester -b --dist --dir='bcBlockGasLimitTest'",
"testBlockchainValid": "npm run build:dist && node --stack-size=1500 ./tests/tester -b --dist --dir='bcValidBlockTest'",
"testBlockchainValid": "npm run build:dist && node --stack-size=1500 ./tests/tester -b --dist --dir='bcValidBlockTest' | tap-spec",
Copy link
Member

Choose a reason for hiding this comment

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

This needs to be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed in 39cc0d5

package.json Outdated
@@ -60,6 +61,8 @@
"minimist": "^1.1.1",
"nyc": "^12.0.2",
"standard": "^10.0.0",
"tap-mocha-reporter": "^3.0.7",
Copy link
Member

Choose a reason for hiding this comment

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

tap-mocha-reporter isn't needed as a dependency here, or is it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, it's not needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed in 39cc0d5

'testBlockchainTotalDifficulty',
'testAPI',
'test'
]
Copy link
Member

Choose a reason for hiding this comment

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

Is this really necessary to duplicate the script names here or could this be done in a more general way? Would we loose much if we just allow this for every command and if it is not there it just breaks?

Copy link
Member

Choose a reason for hiding this comment

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

Hi @danjm, can you give a short opinion on the two questions above?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is there so that we can distinguish which tests need to be run with npm run and which with node.

One approach we could take is to read the npm scripts dynamically.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

d9b4ea9 changes scripts/formatTest.js so that it reads directly from package.json. This removes the need to hard code any script names and make any changes to the file if/when package.json is changed.

@holgerd77
Copy link
Member

Ah, and please also rebase on the way.

@holgerd77
Copy link
Member

Any updates here?

@danjm
Copy link
Contributor Author

danjm commented Oct 11, 2018

@holgerd77 Apologies for the delay. I will be incorporating your requested changes later this evening. I have answered your above two questions.

@danjm
Copy link
Contributor Author

danjm commented Oct 11, 2018

@holgerd77 I have made changes in response to your comments and have rebased onto the latest master.

Copy link
Member

@holgerd77 holgerd77 left a comment

Choose a reason for hiding this comment

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

Ok, great, this now looks good, will merge.

@holgerd77 holgerd77 merged commit e9b60a1 into ethereumjs:master Oct 15, 2018
@holgerd77
Copy link
Member

One note: we use linting on all our libraries for a unified code formatting and it is good to accommodate to always run a last "npm run lint" before pushing (now directly fixed a linting error, forgotten semicolon), I often forget this myself though. 😄

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

Successfully merging this pull request may close these issues.

4 participants