Offering unit testing help

[dgreene1]

After #20 is complete, I'd be interested in helping to write some unit tests. Would @joeldenning be able to write some expectations here so that I can fill out the setups?

The following are just ideas. I'm open to however you want to help me to help you guys add test coverage. Since you @frehner and @joeldenning have been so kind, I'd really like to find a way to repay that kindness and to give back to the single-spa community. :)

In other words, if I was provided information I would be able to write the test code:

• Given the following setup (i.e. Arrange)
• Under this action (i.e. Act)
• I expect this (i.e. Assert)

And example might be:

• Given a malformed import map
• That a user tries to patch
• I expect a 400 error with a message of "The import map was malformed"

[joeldenning]

Hey @dgreene1, sure that would be awesome. Lack of tests are a big thing holding back this project - there are a lot of organizations that use the latest docker image, but we don't have any confidence when merging that our changes don't break anything.

I think a few e2e tests would be the most useful place to start. Ones that boot up the web server and make network requests to it, verifying correct behavior. The web server defaults to using the file system as an IO method, and I think that fits the test. One challenge is ensuring that the test order execution doesn't matter - if there's only one import map on the file system, there's no way currently to reset it at the beginning of each test so that each test is starting from a clean slate. So that might be something to add.

As you dive into the code, I think you'll notice that it's sorta old and was originally written by a python developer with less experience in javascript. There are places where the code is a bit weird, but it gets the job done.

Here are a few test cases:

• "Given a brand new import map, I can retrieve the empty map, update it via PATCH /services, and retrieve it after the update, verifying that the updated map has my newly changed module in it"
• "Given a brand new import map, I can update it via PATCH /import-map.json, and retrieve it after the update. I expect the updated map to have all of my changes to the imports merged into it, but older modules to still exist if they were omitted in the PATCH"
• "I can retrieve all environments, depending on my config file"

Once we have tests we also would want to run them in a CI process during every pull request. Travis CI, Circle CI, or Github Actions all work, and I'm happy to help get those set up by granting any permissions to them that they need to run in this project.

[joeldenning]

You can look at #20 for reference, although I don't think I'd start on that branch since it's really old and has some issues. There used to be tests for this project a few years ago and that PR was an attempt to revive them. However, I think it would be better just to start from scratch - those tests are sorta nasty and test things from back when this project was called sofe-deplanifester and dealt with sofe manifests instead of import maps.