-
Notifications
You must be signed in to change notification settings - Fork 213
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
Concurrency didn't work in single file with multiple tests #2174
Comments
Concurrency is only supported between separate test suites, so the way to get concurrency in this situation today would be to split up this suite into multiple suites. The semantics of running individual tests within a suite concurrently are probably a lot harder to define than it seems - especially when you consider setUpAll/tearDownAll as well as any code that runs in It is also not always going to be the case that running tests within a suite concurrently would actually make them faster, sometimes it would be slower (if most of the work is actually in shared code that has to run for all tests, but only once). |
If we did want to support this, one idea could be configuration via either |
Ty for your answer. I'm a bit lost. What is a test suite ? It's a file containing tests ? |
Correct, each test "suite" is a different program (which also makes running them concurrently trivial). They are typically |
Okay understood. A solution could be to have a function like group named suite which will do that ? |
Possibly, but it would be quite a lot of engineering work to support, compared to the current model. On the other side the benefit is relatively minimal, compared to just creating separate files? |
It will be painful to maintain for example if it's based on an enum or an Iterable logic. Also, when the list is 'huge' like 100, creating and maintain 100 files will be hard. Edit : Also, on my app, the files which need this feature are not big at all, many time it's just few lines... |
I would argue that it is easier to maintain 100 smaller files than one gigantic file personally. Although I understand some others have a preference for huge files. Either way the amount of code is essentially the same though. If it were relatively trivial to implement, I think we would have support, since we generally want to support people working how they want to work. But in this case it is actually quite challenging. Beyond just the actual implementation (which in itself could be quite complicated depending on the desired semantics), actually defining how it should work is also quite challenging. As an example, note that any sort of concurrency at the suite level is also going to bring up a bunch of questions regarding variable state. Today it is common practice to create local or global variables, assign to them in |
Description :
In the following example, I want to run tests in parallel to improve speed.
This tests took 1 minutes and 41 seconds...
Actual behavior :
If you run the code bellow, you will see that test are run one by one, group by group...
Expected behavior :
Test must be run in parallel
Code sample
Console log
Flutter doctor -v
The text was updated successfully, but these errors were encountered: