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
BigDiffTest takes compared to all other tests a rather long time, for me it needs about 4 minutes.
Apparently most of that time comes from writing 100000 (!) files. Could you please check if there are other ways to implement this test?
Long build / testing times make it less attractive for people to run the tests, which could decrease code quality. Additionally writing that many files puts in my opinion an unjustified amount of work on the file system.
The text was updated successfully, but these errors were encountered:
@TheSnoozer, my suggestion would be to remove / disable the test (or if really necessary, at least only run it on CI)1. I know this is not a great solution, but in my opinion creating 100.000 files is out of proportion to what this test is covering.
Take a look for example at the recent GitHub "Run basic test with Java" workflow runs: The "Build with Maven" step takes ~1 minute, and of that BigDiffTest takes ~35 seconds. That is more than 50% of the complete Maven build taken just by that one test.
But in the end it is of course your decision. If you think this is justified, then just keep it as it is.
Footnotes
Another alternative would be reducing the number of created files. But this would still cause a lot of work for your drive, and might not even trigger the situation anymore where the Git process produces enough console output to cause a deadlock, defeating the purpose of the test. ↩
BigDiffTest takes compared to all other tests a rather long time, for me it needs about 4 minutes.
Apparently most of that time comes from writing 100000 (!) files. Could you please check if there are other ways to implement this test?
Long build / testing times make it less attractive for people to run the tests, which could decrease code quality. Additionally writing that many files puts in my opinion an unjustified amount of work on the file system.
The text was updated successfully, but these errors were encountered: