-
Notifications
You must be signed in to change notification settings - Fork 586
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
Run multiple xUnit.net test libraries as one test suite #797
Comments
If xunit2 allows to natively run tests in parallel then we should use that feature. I assume the xunit2 helper was basically copied from the xunit helper (which is still there for backwards compatibility) and we didn't know about that feature. Tl;dr pull request would be very welcome |
Would you like to change the behaviour of the xunit2 helper? This would be the simplest change, I think, but could be argued to be a breaking change. Or would it be better to add a flag to |
In this case I would argue a breaking change is OK since from what I can understand it's the default in xunit2. Adding a RunSynchronously flag to restore the current behavior would be nice. |
OK, sounds good. I'll take a look at it this weekend, I hope. |
This was also something that I was very much looking to do as well. I would like to see the xunit tasks converge on the parameter style of the nunit and mspec tasks, e.g. being able to specify what the output file names should be rather than just providing a Caveat being that, again, it's a breaking change. |
@neoeinstein Good points. Perhaps you should go first, then 😄 As I look through Thus, it may make sense to make your suggested change first, because that would effect that necessary decoupling first. |
This commit is a general rewrite of the xUnit2 task. This rewrite breaks compatibility with prior versions using the xUnit2 task. Changes include: dropping the ConfigFile parameter, use Option type instead of null for optional parameters, specify report file names instead of boolean flags, use a list of name-value tuples for specifying tasks. This commit allows the parallel execution of multiple xUnit test assemblies from a single task using the parallelism features in the xUnit console runner. (Fixes fsprojects#797)
This commit is a general rewrite of the xUnit2 task. This rewrite breaks compatibility with prior versions using the xUnit2 task. Changes include: dropping the ConfigFile parameter, use Option type instead of null for optional parameters, specify report file names instead of boolean flags, use a list of name-value tuples for specifying tasks. This commit allows the parallel execution of multiple xUnit test assemblies from a single task using the parallelism features in the xUnit console runner. (Fixes fsprojects#797)
This commit is a general rewrite of the xUnit2 task. This rewrite breaks compatibility with prior versions using the xUnit2 task. Changes include: dropping the ConfigFile parameter, use Option type instead of null for optional parameters, specify report file names instead of boolean flags, use a list of name-value tuples for specifying tasks. This commit allows the parallel execution of multiple xUnit test assemblies from a single task using the parallelism features in the xUnit console runner. (Fixes fsprojects#797)
This commit is a general rewrite of the xUnit2 task. This rewrite breaks compatibility with prior versions using the xUnit2 task. Changes include: dropping the ConfigFile parameter, use Option type instead of null for optional parameters, specify report file names instead of boolean flags, use a list of name-value tuples for specifying tasks. This commit allows the parallel execution of multiple xUnit test assemblies from a single task using the parallelism features in the xUnit console runner. (Fixes fsprojects#797)
This commit allows the parallel execution of multiple xUnit test assemblies from a single task using the parallelism features in the xUnit console runner. (Fixes fsprojects#797)
This is extremely helpful! Thank you! 😄 |
When using the 'raw' xUnit.net 2 console runner, it's possible to run multiple test libraries as a single test suite, simply by supplying all the library files on the command line. Here's an example:
There are multiple advantages of doing this. First of all, the output includes a test execution summary, with totals and grand totals. Here's an example:
Another advantage is that if you ask the test runner to parallelise the suite, it runs all discovered tests in parallel, as can be seen in this example:
Notice how discovery completes for both test libraries before execution starts.
This isn't how FAKE currently works. As far as I can tell from the code, FAKE runs each test library independently.
This means that I never get a single summary, and I can't parallelise all tests.
Is there a way to configure it so that it runs all libraries as a single test suite?
If not, could there be?
I'll be happy to attempt a PR, but before I do that, I wanted to ask if I'd missed something, and if not, if this feature is wanted.
The text was updated successfully, but these errors were encountered: