-
Notifications
You must be signed in to change notification settings - Fork 51
support parallel test execution #260
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
base: main
Are you sure you want to change the base?
Conversation
I couldn't help myself and just added test lookup functionality (right click on test -> Go to Test). This leads to the source file that a test exe is built from. This only works for simple tests that are made up of one source file, but that should be the majority of tests. |
1523925
to
b94ce5d
Compare
@Jannik2099 do you think this PR is ready to go? Sorry it's taken me a long time to get to it |
d70915c
to
ecdb6f2
Compare
Sorry for the delay, I managed to break my finger which made interfacing with a keyboard... difficult. I addressed all your points. |
I guess this slipped my mind when cutting the new release. Is there any way you could rebase on main, so I can get this for 1.28? |
ecdb6f2
to
504f766
Compare
No worries, I rebased & tested that things still work as expected. |
Thanks for your work. Will review next week. |
ping? |
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.
Some initial comments
src/tests.ts
Outdated
// this is far from complete, but should suffice for the | ||
// "test is made of a single executable is made of a single source file" usecase. |
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.
Are you going to complete this TODO
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.
No.
The comment is about tests that consist of multiple TUs, or tests that are not native meson tests (see https://mesonbuild.com/Reference-manual_functions.html#test_protocol ) - I don't have a good idea on what projects using these options look like, as I personally only use single TU tests.
I'm not sure if there is a simple solution for these, and "single TU tests" should cover the majority of users.
504f766
to
cea0d04
Compare
converted back to draft as I discovered a minor issue - parallel runs could spawn parallel compile jobs. |
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.
Getting close!
Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
this is required when targets exist twice, e.g. due to subprojects Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
bbab54b
to
3fe2a98
Compare
otherwise multiple simultaneous test runs may trigger rebuilds Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
3fe2a98
to
93ad6d6
Compare
ping? |
Sorry, I haven't had much time to look at your PRs. I promise to get to them soon. |
This adds parallel test execution through the vscode TestController API. Sequential tests
test(..., is_parallel = false)
are respected.Parallelism is set to the number of CPUs, if desired I could also add a config option.
I also fixed output formatting of test failures as
vscode.TestRun.appendOutput
always expects CLRF.