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

test: simplify test_runner.py #29497

Merged
merged 1 commit into from Mar 14, 2024

Conversation

tdb3
Copy link
Contributor

@tdb3 tdb3 commented Feb 28, 2024

Implements the simplifications to test_runner.py proposed by sipa in PR #23995.

Remove the num_running variable as it can be implied by the length of the jobs list.

Remove the i variable as it can be implied by the length of the test_results list.

Instead of counting results to determine if finished, make the queue object itself
responsible (by looking at running jobs and jobs left).

@DrahtBot
Copy link
Contributor

DrahtBot commented Feb 28, 2024

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK mzumsande, davidgumberg, marcofleon

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

@DrahtBot DrahtBot added the Tests label Feb 28, 2024
@kevkevinpal
Copy link
Contributor

I tried this with --failfast and it seemed to properly fail fast

@tdb3
Copy link
Contributor Author

tdb3 commented Mar 2, 2024

I tried this with --failfast and it seemed to properly fail fast

Thank you for the test

@kevkevinpal
Copy link
Contributor

I tested with this diff e82b342

and ran ./test/functional/test_runner.py --failfast

@@ -613,14 +613,12 @@ def run_tests(*, test_list, src_dir, build_dir, tmpdir, jobs=1, enable_coverage=
max_len_name = len(max(test_list, key=len))
test_count = len(test_list)
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we can remove test_count? See below.

Copy link
Contributor Author

@tdb3 tdb3 Mar 11, 2024

Choose a reason for hiding this comment

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

test_count being assigned outside of the loop enables reporting of the correct number of total tests on the right side of the /.

if failfast and not all_passed:
break
for test_result, testdir, stdout, stderr, skip_reason in job_queue.get_next():
test_results.append(test_result)
i += 1
done_str = "{}/{} - {}{}{}".format(i, test_count, BOLD[1], test_result.name, BOLD[0])
done_str = "{}/{} - {}{}{}".format(len(test_results), test_count, BOLD[1], test_result.name, BOLD[0])
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: We could use an f-string here and replace test_count with len(test_list)

Suggested change
done_str = "{}/{} - {}{}{}".format(len(test_results), test_count, BOLD[1], test_result.name, BOLD[0])
done_str = f"{len(test_results)}/{len(test_list)} - {BOLD[1]}{test_result.name}{BOLD[0]}"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, updating to an f-string better aligns with the style guidelines (and that line is being changed anyway).
Leaving other format strings untouched for now (those could be updated in another refactor PR).

@tdb3 tdb3 force-pushed the 20240227_testrunnersimplification branch from 0dfd4c2 to 8f2d814 Compare March 11, 2024 21:55
@tdb3
Copy link
Contributor Author

tdb3 commented Mar 11, 2024

Thanks for the review @davidgumberg!
Force pushed. Responses inline.

Copy link
Contributor

@marcofleon marcofleon left a comment

Choose a reason for hiding this comment

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

Tested ACK 8f2d814.

Reviewed the code changes and I think they make the program a bit more readable. I ran test_runner.py and there were no issues. Also tested with --failfast and it did indeed fail fast at the expected test.

@davidgumberg
Copy link
Contributor

reACK 8f2d814

Copy link
Contributor

@mzumsande mzumsande left a comment

Choose a reason for hiding this comment

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

Code Review ACK 8f2d814

@tdb3
Copy link
Contributor Author

tdb3 commented Mar 12, 2024

Tested ACK 8f2d814.

Reviewed the code changes and I think they make the program a bit more readable. I ran test_runner.py and there were no issues. Also tested with --failfast and it did indeed fail fast at the expected test.

Thank you for the review @marcofleon!

@tdb3
Copy link
Contributor Author

tdb3 commented Mar 12, 2024

Code Review ACK 8f2d814

Thank you for the review @mzumsande!

Remove the num_running variable as it can be implied by the
length of the jobs list.

Remove the i variable as it can be implied by the length of the
test_results list.

Instead of counting results to determine if finished, make the
queue object itself responsible (by looking at running jobs and
jobs left).

Originally proposed by @sipa in PR bitcoin#23995.

Co-authored-by: Pieter Wuille <pieter@wuille.net>
@tdb3 tdb3 force-pushed the 20240227_testrunnersimplification branch from 8f2d814 to 0831b54 Compare March 12, 2024 22:00
@tdb3
Copy link
Contributor Author

tdb3 commented Mar 12, 2024

rebased

@mzumsande
Copy link
Contributor

re-ACK 0831b54

rebased

Why? This looked ready for merge with 3 ACKs. A rebase invalidates existing ACKs, so once these exist it should only be done if there is a conflict (Drahtbot will complain) or a specific reason (such as. a silent conflict). The CI will always rebase on master anyway for its runs (which could be restarted without rebasing if really necessary).

@tdb3
Copy link
Contributor Author

tdb3 commented Mar 12, 2024

re-ACK 0831b54

rebased

Why? This looked ready for merge with 3 ACKs. A rebase invalidates existing ACKs, so once these exist it should only be done if there is a conflict (Drahtbot will complain) or a specific reason (such as. a silent conflict). The CI will always rebase on master anyway for its runs (which could be restarted without rebasing if really necessary).

Thank you for the insight, didn't realize that. I'll avoid that moving forward. The rationale was to bring it to head while reinitiating CI (MacOS brew issue).

@davidgumberg
Copy link
Contributor

reACK 0831b54
Verified that the commit is unchanged with range-diff, and re-ran make check:

$ git range-diff a945f09...8f2d814 1105aa4..0831b54
1:  8f2d814407 = 1:  0831b54dfc test: simplify test_runner.py

Copy link
Contributor

@marcofleon marcofleon left a comment

Choose a reason for hiding this comment

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

re-ACK 0831b54

Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

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

lgtm

@fanquake fanquake merged commit 6850d72 into bitcoin:master Mar 14, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants