Codi tests documentation and options

[dbauszus-glx]

The xyz/TESTING.md needs to be reviewed and should be referenced in the xyz/DEVELOPING.md document.

1. It should be possible to run the codi tests with just the workspace option, without the need to first setup an ACL, register a user, approve the user, etc.

2. The security strategy test should perhaps be separate from mapp module tests.

3. user [roles] could be spoofed for tests.

4. A POSTGIS test database should be made available for replicating tests. It is possible to dump and restore a data on Postgres hosted with NEON. https://neon.tech/docs/import/import-from-postgres

5. Perhaps we can make the test database available as bak file with instructions for restoring the data.

6. Tests should be focused on modules and only include required modules. eg. The featureFormats requires the featureFields module. Tests for the featureFormats module should not require other modules in the test. The featureFields should be tested individually prior to the featureFormats which require the featureFields module.

7. Is it possible to import assets in tests? Test for synchronous functions should not include await xhr for assets making the test async.

[RobAndrewHurst]

1. We would need to figure out how we handle workspaces with or without roles.

2. Agreed.

3. Yeah that's a great idea for the user roles will tie in with 1.

4. That could be really good, we should maybe make a way to automate this. Possibly a function we write into ignite to pull and censor data.

5. Maybe.

6. So I agree that the tests should be more granular to functions, but we also want to test an entire process. So if its updating a location for example, we will want to call the function that uses all the functions that are included. Another example of this was getting a location to update to then trigger the icon_scale.max value to be recalculated. So we can test the featureFormats wkt function. But we need to see it's acting as it should in further processes. So it's like we need to think about micro and macro tests.

7. Yes we can, but it will have to be via a request. So I have exposed the tests directory in express, and you can just create a request to get the asset you want. I do this with the decorate layer test.

workspace_layer = await mapp.utils.xhr(`/test/api/workspace/layer?layer=decorate`);
workspace_layer.mapview = mapview;

[RobAndrewHurst]

Additions.

Bundle the test suite so that assets exist in the browser allowing us to remove the need to import files via a request and to expose the tests directory in the express.js. This will also allow us to run these tests in deployed environments and codepens.

We can make it very easy for 3rd parties to test out any bugs of their software using our inputs and tests.