Determine if there is a workflow for github actions for javascript testing that does not use node.js infrastructure

[dhrogers]

The current github action for javascript testing uses npm and other node.js infrastructure. Currently the code base does not use Node.js, so this is an issue if we move forward with this testing framework.

See action in the repository at: .github/workflows/jest.yml

I have been unable to find a javascript actions workflow that does not use node.js.

The question is: does the use of github actions require node.js infrastructure for testing javascript? If so, we need to adapt to this.

[camtauxe]

I spent all morning researching various solutions and the past hour writing a long response detailing all of my findings, but then figured It'd be best to keep it short:

Ultimately, the only alternative to running our tests within Node will be to run the code within an actual browser. Naturally, this is hard to automate. Karma is a test-runner that can do this for us. There may be others, but Karma was the first that came up and seems pretty popular. However, Karma is itself written in and installed through Node/npm. So introducing Node to our project in at least some capacity seems like an inevitability.

I want to stress that adapting our code to use Node really isn't as scary as it sounds. People develop and test browser-only libraries with Node all the time, and most of the rewrites to the code itself that would be needed are rewrites that we will have to do soon anyway as part of making our code into a well-behaved Javascript library. In my research, I found that Jest along with some other tools will give us everything we need to unit-test browser-specific functions (like DOM manipulation) all within Node.

Once in place, Node has a lot of advantages it can give us. We could use it to manage our dependencies (like d3 and Three.js), build/minify the GTK library, test it and many other things. And new developers on the project can get up-and-running just by running 'npm install.'

[camtauxe]

To elaborate on an alternative to Karma, there's also Selenium which is a tool for drving/automating web browsers. This is lower-level than any one test framework, but we would be able to automate and control the browser from another language or test framework, like Python. That way, we can keep our Javascript code exactly as messy as it is and avoid using Node.js entirely. Of course, we'd also miss out on the ability to do any precise unit-testing, since we'd basically be testing the entire thing at once. Frankly, this seems to me like a lot more trouble than any node-based solutions, So I'd only recommend it if you are, for some reason, ideologically opposed to using Node and think its worth going through the extra trouble just to avoid it.

[dhrogers]

Thanks for doing the research. I'm not opposed to using Node. In fact, I've been working on these tests this AM and it's quite nice. Seems like the node stuff is standard, so I'm all for switching over to that.

At the moment, I'm creating a client object so that we can unit test at the server API level, and encapsulate the communication in an object. This will remove all the knowledge of GET protocol from the GTK objects, which is a good thing.

We can work through this when I get back.

• David

[camtauxe]

Sounds good. I'll be brainstorming some ideas on how best to handle transitioning to Node.

[camtauxe]

We've already completed the move to NodeJS for the client-side Javascript, so this issue is now moot. Closing.