TheAlgorithms/JavaScript

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

defaude opened this issue · 9 comments

defaude commented

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 commented

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 commented

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 commented

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.

  • 👍1
raklaptudirm commented

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

utkarsh-shrivastav77 commented

Is this issue still open to contribute

appgurueu commented

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

utkarsh-shrivastav77 commented

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

appgurueu commented

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 commented

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.