@Akhilesh-max Thanks for reporting. Some questions:

• What are the full specs of your machine?
• Is https://stackoverflow.com/questions/19683846/why-are-my-angularjs-karma-jasmine-tests-running-so-slowly relevant?
• Does anything else run slowly on your Mac, or is it just the frontend tests of Oppia?
• Could you ask around (on discussions, team chats, etc.) to see if anyone else is running into this issue and what specs their machines have? Let's try and see if there's any commonality between the folks who run into this issue, and that is different from the folks who don't. Otherwise it's not clear whether the issue is M1 chips or something else.

Thanks!

@seanlip
I am using MAC m1 :
Hardware specs ::

software ::

memory usage during execution ::

I think, perhaps this ain't the reason.

Also, the problem continues with the end-to-end (e2e) tests as well. Running the learner dashboard test took me 16 minutes. The situation becomes even more peculiar with the Lighthouse tests. However, the acceptance tests seem to be running well, taking between 30 to 120 seconds for each suite, depending on the specific suite.

I tired following the suggestions in the reference. However, even running the e2e tests without minimizing or changing the tab, does not helps much.

I will open discussion to see if there are other folks facing similar issues either on the same or any other device.

@seanlip Interestingly, switching from ChromeHeadless to ChromiumHeadless resolves the issue, and the entire frontend tests completed in just 3.9 minutes in the same machine.

Take a look:

I guess, the problem might be due to Chrome not being fully optimized for the ARM architecture, which the Mac M1 is based on. Previously, there were no such compatibility issues with Intel-based chips (x86 Architecture). Could this be the reason for the observed behavior? However, I’m unsure if we can move to chromiumHeadless.

@Akhilesh-max That's great! So it seems like the issue is Chrome rather than the tests.

Is Chrome much slower when you're regular using it too, or just in the karma env? There are some mentions of that online, but I don't know if the solutions help.

I'm totally fine with switching to ChromiumHeadless but we can't really do this globally since not everyone has Chromium. But if you can configure karma to use either one (or even Firefox) based on a per-developer system preference then I think that should be fine. Do you want to have a go at that?

@seanlip Actually Headful or non-headless chrome works pretty fine otherwise, may be the issue rests with the optimisation of Headless with the ARM architecture.

Also, I was thinking to use the Karma Detect Browsers plugin to identify the available browsers on the machine and prioritize them in the following order: ChromiumHeadless, ChromeHeadless, and FirefoxHeadless for the execution. If there are any issues with the plugin or it doesn’t function as anticipated, I plan to default to ChromeHeadless.
Does that sound correct?
If not, please suggest.

It seems reasonable. I don't have a strong opinion; as long as it works and it's conceptually easy for developers to understand what's going on, I'm fine with anything.

@seanlip, interestingly, the issue of slow execution of frontend tests on my Mac M1 has unexpectedly resolved itself. This happened despite no changes to the karma configuration file, and I’m still using the same device and ChromeHeadless for testing. I’ve been unable to identify any recent PRs that could have led to this. I also reviewed the release notes for the latest version of Chrome (123.0.6312.87), but found nothing relevant. The last time I ran the tests, it was on Chrome version 122.0.6261.94. Also, I confirmed It with another team member with a Mac M1 and the issue has been resolved for him as well. Could it be the new release of chrome?

Thanks @Akhilesh-max, I'm glad it resolved itself and I appreciate your keeping the issue updated.

Yes, that is certainly a possibility -- in these sorts of things, one needs to focus on "what changed", and Chrome is one of the possibilities. (It's unrelated, but you might find some of these stories amusing.)

Should we close this bug then?

@seanlip, thanks. It really would be interesting to go through these lores.
I agree that since the issue has been resolved, it seems ok to close it.

Additionally, should we consider documenting the typical duration (assuming sufficient resources) for these tests to execute properly in the wiki docs? I’ve been in contact with another contributor who also uses an M1 and has been with Oppia for a while. He experienced something similar and felt it was normal. Perhaps this information could be useful to others.

Additionally, should we consider documenting the typical duration (assuming sufficient resources) for these tests to execute properly in the wiki docs?

Sure, go for it. Feel free to open an issue on the wiki repo and assign it to yourself if you like, thanks!

@Akhilesh-max Have you filed the bug yet? If so, please link to it here, thanks!

Additionally, should we consider documenting the typical duration (assuming sufficient resources) for these tests to execute properly in the wiki docs? I’ve been in contact with another contributor who also uses an M1 and has been with Oppia for a while. He experienced something similar and felt it was normal. Perhaps this information could be useful to others.

I also used to experience long testing times and didn't think much of it. It's much faster now. I can provide you with my specs and (present) execution times if that helps with documentation

oppia/oppia-web-developer-docs#302

Here's the issue link.

Hi @agallop, could you please share the current duration of the execution and the device you're using? This information could be helpful for our documentation. For reference, I'm using a Mac M1 and the execution time is now between 3-5 minutes.

Thanks.