You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In principal, there's no reason that tests within a spec class couldn't be executed in parallel. Although for smaller specs with trivial tests, the overheads might outweigh the benefits.
If this is opt-in, then it doesn't need to be a breaking change (no major version bump). Could just add a .inParallel() method to SpecificationNode (would have no useful effect on leaf nodes).
If this is opt-out, it would be a breaking change. Would need to add a .inSeries (or similar) method to SpecificationNode (neat advantage of being able to opt-out for a single nested node within a class). Could also potentially opt-out automatically in certain circumstances, e.g.:
Tests subject to a TestRule that inherits from ExternalResource
Have a custom SharedState annotation that could be applied to test rules and spec classes
If executing in parallel, would need to worry about reporting order. Could maintain order by gathering all results and reporting at the end of the class (might mess up surefire's timing reports), or just be explicit about how test order is/isn't maintained.
The text was updated successfully, but these errors were encountered:
In principal, there's no reason that tests within a spec class couldn't be executed in parallel. Although for smaller specs with trivial tests, the overheads might outweigh the benefits.
If this is opt-in, then it doesn't need to be a breaking change (no major version bump). Could just add a .inParallel() method to SpecificationNode (would have no useful effect on leaf nodes).
If this is opt-out, it would be a breaking change. Would need to add a .inSeries (or similar) method to SpecificationNode (neat advantage of being able to opt-out for a single nested node within a class). Could also potentially opt-out automatically in certain circumstances, e.g.:
If executing in parallel, would need to worry about reporting order. Could maintain order by gathering all results and reporting at the end of the class (might mess up surefire's timing reports), or just be explicit about how test order is/isn't maintained.
The text was updated successfully, but these errors were encountered: