[Typescript] Convert tests to jest and karma

[HarelM]

Current tests are using tap and testem which are not commonly used test runners.
We should use the industry standard in order to make sure we don't get stuck in an old version that doesn't support changes.
This applies to node running tests such as test-unit, test-build, test-query.
This also applies to browser tests such as test-query.
This is a big task, so I decided not to do it as part of #209.

[astridx]

Does any one work on this?

I am making my first steps with jest here: https://github.com/maplibre/maplibre-gl-js/compare/main...astridx:jest?expand=1
So far I have only set up the environment and implemented a test as an example. I'm not sure enough yet whether I can do it. That's why I haven't submitted a PR yet.

I would find it good to develop the new tests in parallel in a separate directory. What is your opinion on this?

I have looked at codemods: https://jestjs.io/docs/migration-guide
As far as I can see, the reworking is more time-consuming than the rewriting. But maybe I have to less experience.

[HarelM]

I'm not aware of anyone currently working on this.
From an architecture point if view I think the best approach would be to place the unit test files next to their source file and to covert the test to typescript and jest.
This is a big task but super interesting :-)
If you create a branch for this other might be able to help.
Note that converting the tests to typescript might mean some tests are invalid due to typings.
Not sure I have more words of wisdom :-) good luck!

[wipfli]

If I understood the Slack discussion correctly it might actually be an option to convert all tests to karma exclusively, right @webberig?

[wipfli]

There are 197 files in test/unit. Do you think this would be a good starting point for migrating the tests from tap to jest? It would be useful if we could do this migration with many smaller pull requests ideally to the main branch. Do you think it is possible to run two test frameworks in parallel for a limited amount of time?

[HarelM]

I think there shouldn't be a problem to run some test using one framework and other using another framework.
We can move the tests that we convert to be next to the file they test so that way a certain framework will look for the file in src and not in test and thus achieving this requirement.
I would advise to start with something small, POC if you'd like, and then decide on the next steps.
Before we convert the first test we can't really grasp the size of this I think...

[astridx]

If I understood the Slack discussion correctly it might actually be an option to convert all tests to karma exclusively, right @webberig?

Was it decided whether to use jest or karma?

[HarelM]

I don't think we came to a conclusion.
Karma seems more appropriate to do the job but it might be harder to setup etc.
I recommend doing a proof of concept and understating which is faster to implement or which is better in terms of less mocks... I don't know...
But the main point is to start small and then decide...

[wipfli]

I always get this feeling that we found an acient city that people have built in the past but now they are not there anymore an we try to understand why they did things the way they did them.

The number of render and query tests is really impressive and I am super glad that migrating them will probably only mean editing one or two files. When it comes to unit tests it looks like there is more handarbeit involved.

[wipfli]

Regarding frameworks I would tend to jest at the moment. A good starting point could be to migrate a single unit test from tap to jest and add a script to package.json to run jest and tap side by side. Would be nice because we could merge to the main branch.

[HarelM]

I always get this feeling that we found an acient city that people have built in the past but now they are not there anymore an we try to understand why they did things the way they did them.

This is spot on! :-)

[astridx]

.. A good starting point could be to migrate a single unit test from tap to jest and add a script to package.json to run jest and tap side by side. ...

Do you mean something like here: #331

[HarelM]

I've added my remarks there. It would be better if you describe what you did and what you plan to do so we can have a better understanding of the big picture.
Thanks!!

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[HarelM]

This is in progress now.

[HarelM]

So how close are we to remove the tap dependency?
It would also be nice to get rid of testem, but that's a bit more problematic, we might consider moving it to a different issue.
We should also consider removing the render and query test infrastructure and use something else, I think, maybe even jest can do the trick, I don't know...
Feels like we are at the last strech when it comes to unit tests, right?

[wipfli]

Only image_source is left on the unit test side of things.

[birkskyum]

Only image_source (#732) and browser test (#810 ), then I believe we can remove tap. I tried to get an overview in the milestone https://github.com/maplibre/maplibre-gl-js/milestone/4

[birkskyum]

For rendering tests, one option could be something like cypress. I'm sure there are other good tools out there, just wanted to put it on the table.

[HarelM]

I would say that cypress should replace sellenium (browser) tests.
But I guess it can help with render tests as well.
Anything is better than this proprietary test harness...

[birkskyum]

Also, playwright seem to pick up tracktion in the e2e space.

[HarelM]

Interesting, this is the first time I'm hearing about it.
Still a long way to go though, I would wait for it to gain more traction before using...
https://www.npmtrends.com/cypress-vs-playwright-vs-puppeteer