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

Support tests sharding natively #42986

Closed
ThomasFerroAgicap opened this issue Aug 23, 2024 · 3 comments
Closed

Support tests sharding natively #42986

ThomasFerroAgicap opened this issue Aug 23, 2024 · 3 comments
Labels
Area-DotNet Test untriaged Request triage from a team member

Comments

@ThomasFerroAgicap
Copy link

Is your feature request related to a problem? Please describe.

We are trying to reduce the time of our CI by splitting the execution between multiple runners.

Describe the solution you'd like

Similar to what we can do in Playwright, I think that implementing sharding in the dotnet test CLI would greatly benefit many projects. One possible API could be based on the previous example:

# The first runner could execute this, running the first fifth of the tests in MyTests.dll
dotnet test "MyTests.dll" --shard 1/5
# Run the second fifth of the tests in MyTests.dll
dotnet test "MyTests.dll" --shard 2/5
# ...
dotnet test "MyTests.dll" --shard 3/5
dotnet test "MyTests.dll" --shard 4/5
dotnet test "MyTests.dll" --shard 5/5

Additional context

We already tried these two solutions that does not completely satisfy us:

Work around the issue by splitting our tests in multiple projects

We can have multiple test projects and configure our CI to split the projects to run between multiple runners. This is not ideal as it forces an architecture upon us, multiplying the projects count for no other purpose than the tests execution.

Keep a single test project and split the tests to run manually

We also tried to implement our own "sharding" by:

  1. Listing all of the tests with the dotnet test --list-tests command;
  2. Split the result in shards in a bash script;
  3. Have one CI runner per shard.

The return of the dotnet test --list-tests command forces us to manipulate it multiple times, removing the headers that cannot be muted and manage the parameterized tests that appears multiple times. Those manipulations are tedious and seem hacky, compared to a native solution provided by the SDK.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-DotNet Test untriaged Request triage from a team member labels Aug 23, 2024
@nohwnd
Copy link
Member

nohwnd commented Nov 13, 2024

@Evangelink do you want to consider something like this for the new testing platform, it won't be added to vstest since we are not adding new features there. Or this won't fit into our plan any time soon?

@Evangelink
Copy link
Member

I think the concept is interesting but I don't know if it can really be a platform feature as it mainly depends upon the framework (e.g. are they discovering all tests before running, is there some guarantee of "order"...)

@Evangelink
Copy link
Member

I cannot move the issue because it's a different org so I recreated it microsoft/testfx#4068.

@Evangelink Evangelink closed this as not planned Won't fix, can't repro, duplicate, stale Nov 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-DotNet Test untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

3 participants