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
{{ message }}
Repository navigation
Project-Euler/test/Problem044.test.js runs for ~ 17 minutes #1193
// Project Euler Second Value for Condition Checktest('if the number is greater or equal to 2167',()=>{expect(problem44(2167)).toBe(8476206790)})
I guess it's because this is running into really, really high numbers, maybe? Neither the CPU nor the RAM usage goes up substantially (at least on my machine) but for some reason, this takes ages to complete.
I just realized this is even more severe as assumed initially: Since we're running the test in a pre-commit hook, the simple act of just committing changes locally becomes a minute-long ordeal...
I just realized this is even more severe as assumed initially: Since we're running the test in a pre-commit hook, the simple act of just committing changes locally becomes a minute-long ordeal...
OOF. Ideally CI & hooks should only run tests on the files that were changed.
While we changed the process so that the pipeline for pull requests only executes changed test files, the issue with the super-long-running test execution. This hinders not only the "regular" pipeline regarding runtime: It also kind of deters people from just running the tests locally as it takes forever. As a result, we have three failing tests right now :)
=> I took the liberty to just .skip the long-running test. This way, we still have the test case for those who want to play around with it and for documentation's sake. But we don't run it every single time.
Activity
defaude commentedon Oct 15, 2022
It's this one:
I guess it's because this is running into really, really high numbers, maybe? Neither the CPU nor the RAM usage goes up substantially (at least on my machine) but for some reason, this takes ages to complete.
defaude commentedon Oct 15, 2022
I just realized this is even more severe as assumed initially: Since we're running the test in a pre-commit hook, the simple act of just committing changes locally becomes a minute-long ordeal...
appgurueu commentedon Oct 15, 2022
OOF. Ideally CI & hooks should only run tests on the files that were changed.
raklaptudirm commentedon Oct 16, 2022
Jest usually caches tests so the precommit hook should not be an issue.
utkarsh-shrivastav77 commentedon May 12, 2023
Is this issue still open to contribute
appgurueu commentedon May 12, 2023
Yes, feel free to optimize the solution to problem 44.
utkarsh-shrivastav77 commentedon May 12, 2023
export { problem44 } instead of this can I use console.log for the answer
appgurueu commentedon May 12, 2023
No, that doesn't improve the performance at all and just harms code quality.
defaude commentedon Oct 1, 2023
While we changed the process so that the pipeline for pull requests only executes changed test files, the issue with the super-long-running test execution. This hinders not only the "regular" pipeline regarding runtime: It also kind of deters people from just running the tests locally as it takes forever. As a result, we have three failing tests right now :)
=> I took the liberty to just
.skipthe long-running test. This way, we still have the test case for those who want to play around with it and for documentation's sake. But we don't run it every single time.test: skip test that's running way too long (#1393)
feat: Test running overhaul, switch to Prettier & reformat everything (…