Project-Euler/test/Problem044.test.js runs for ~ 17 minutes

[defaude]

I just stumbled upon this gem while executing the tests locally and then wondering what's going on.

See https://github.com/TheAlgorithms/JavaScript/actions/runs/3255189818/jobs/5344248296#step:5:161

@raklaptudirm what do you think? Should we

1. disable the test so it's skipped and doesn't clog up our CI
2. figure out why this immense delay happens, fix the test (or the implementation) and re-enable the test once we're good

[defaude]

It's this one:

  // Project Euler Second Value for Condition Check
  test('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.

[defaude]

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]

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.

[raklaptudirm]

Jest usually caches tests so the precommit hook should not be an issue.

[utkarsh-shrivastav77]

Is this issue still open to contribute

[appgurueu]

Yes, feel free to optimize the solution to problem 44.

[utkarsh-shrivastav77]

export { problem44 } instead of this can I use console.log for the answer

[appgurueu]

export { problem44 } instead of this can I use console.log for the answer

No, that doesn't improve the performance at all and just harms code quality.

[defaude]

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.