-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
feat(forge test): stream test results #798
Conversation
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.
Tested with forge test
, forge test --gas-report
and forge test -vvvvv
and it all worked as expected (tested on solmate). It didn't make much of a difference on my machine, but I'm sure it will on someone elses. Great work!
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.
Nvm, it actually isn't really using the channel as we discussed - the call to runner.test
blocks since we're waiting for results, so the receiving/outputting loop is not run until that finishes and the behavior is the same as if we were not using a channel
@onbjerg yeah, I think we'll have to ditch the |
Also something to consider: AFAIK this streams results on a per-contract basis, do you think we could do something like a streaming terminal that fills stdout across the entire board, by dynamically adding new contract tags as tests for that contract complete? example:
then when Contract::testContract1() completes it does:
then when another contract test completes, it'd do
and then when contract 1's other function completes it'd show
|
@onbjerg can keep the @gakonst could store the lines in memory and redraw the whole set as it updates. I'm not sure what terminal lib would work but seems doable? I'd worry about messing up scrolling or having updates appear offscreen though. If it does behave with scrolling though it would be pretty cool. |
I think this is good for terminals where we cannot move the cursor back (like CIs) and then for interactive terminals we could do what @gakonst suggested with https://github.com/fdehau/tui-rs (see the paragraph example). Will give this a go again |
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.
Works as intended now 😄
This does appear to be running tests in sync again whereas an earlier version did not. Needs more investigation |
Actually, no, this seems to be working as expected. These are tests with hashing in a loop, the last part of the test fn name is how many times the loop runs. First test setup:
Tests print at approximately the same time but in indeterminate order. This is expected. Second test setup:
Tests stream in that order consistently. This is also expected. @gakonst @onbjerg we agree that's expected behavior, right? Maybe I'm overlooking something. |
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.
Merging cautiously. This PR made me think that it's worth extracting our integration tests from here to Criterion benchmarks
} | ||
let mut gas_report = GasReport::new(gas_reports.1); | ||
let (tx, rx) = channel::<(String, BTreeMap<String, TestResult>)>(); | ||
let known_contracts = runner.known_contracts.clone(); |
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.
Is this not expensive to clone each time?
My intuition would be no but I'd be happy to quantify it somehow -- or possibly just remove the |
Let's leave as-is, no big deal and want to be respectful of your time invested in this already. Thank you again! |
Thanks @gakonst 🤝 |
@gakonst this adds streaming for test results. Makes the UI more responsive for large projects / older machines.