Automated tests for the community assets

[trichoplax]

Is your feature request related to a problem? Please describe. Recently the automated leaderboard for the Code Golf community developed a bug - Missing usernames on leaderboard. The JavaScript that produces this leaderboard can be found in public/assets/community. There do not appear to be any automated tests for the code in this folder. It is outside the app folder and it is not clear to me where such tests would belong.

Describe the solution you'd like Could we have tests for the community-specific code in this folder? Where should such tests live? Will it be possible to include them in the CI so that we are automatically alerted of failures?

What approach would also work for other instances of QPixel, that do not have Code Golf and Judaism, but may have their own custom CSS and JS for some of their communities?

[Oaphi]

On a related note, I'd move our community assets to separate repositories and start publishing them as packages - I don't think they belong to the "core" for a couple of reasons:

• QPixel is supposed to be an engine anyone can use without being a part of our network;
• it tightly couples them to our deploy cycle, meaning that any, even trivial change to those has to wait till we can deploy;

That said (and part of the reason why I am bringing it up here), such a change would make it harder to add them to our CI pipeline. It doesn't make it impossible, though, we'll just have to be a bit more creative with setting it up.

[trichoplax]

Sounds good. Having a separate repository per community (and presumably environment variables pointing to them from QPixel?) would mean we could keep the tests for each community in that community's repo, so the tests for QPixel are only those relevant to other instances. Then a community is free to write many/long/inefficient tests without having any effect on QPixel development.

I have no idea how to pull QPixel in for running the community repo tests, but if it's possible I'd like to see that at some point.

[cellio]

I'm not sure it needs a repo per community. A way to separate our network's add-ons from the core code base would seem to meet the need and be less complex? (In other words, think instance, not community within instance. This might also be easier for other instances to emulate.)

[Oaphi]

Splitting between "core" and "community" is also an option, yes - I don't have a strong preference either way as long as we keep a clear distinction between the engine and the stuff that is instance-specific. Having a repo for all comminity-related assets doesn't affect our ability to publish them as packages as well (although it's a bit more complex to set up) - it can be a monorepo with multiple packages (it's common practice as well, see, for example, DefinitelyTyped that provides typings for various npm packages)