Move slow tests from `npm test` to a different test task

[bajtos]

Most of our test suite is running pretty fast, with individual tests finishing under 100ms. However, there are also several slow tests that take more than 1 second to finish. These tests are typically end-to-end/acceptance-level tests that are running running child processes, npm install and so on. As a result, npm test takes too long to complete (about 3 minutes on my machine).

Let's find a way how to reorganize our code base so that these slow tests can be put into "acceptance" or "end-to-end" group, excluded from npm test and have a dedicated CI job to run them in parallel with other CI tasks, as we are already doing for acceptance/repository-mysql and friends. (Alternatively, we can run the slow acceptance tests after the faster tests passed succesfully.)

1. For example, we can introduce new package(s) in the acceptance folder, e.g. acceptance/cli-e2e-tests and move the slow tests there. This should be easy to implement, but requires more work to introduce e2e tests for new packages.
2. Create a new directory-layout convention for acceptance/end-to-end tests, so that we can keep e2e tests inside each package alongside other tests, but still be able to exclude these tests from monorepo-level npm test. For example, we can introduce src/__acceptance__ directory for such tests.

Personally, I think the second option is much better.

List of very slow tests

Tests that take longer than one second to complete, sorted from the slowest:

• app-generator (SLOW) passes npm test for the generated project: 12441ms
• Benchmark (SLOW) works: 4352ms
• lb4 relation generates model relation for existing property name verifies that a preexisting property will be overwritten: 2675ms
• lb4 relation add new controller to existing index file check if the controller exported to index file : 2026ms
• lb4 relation add controller to existing index file only once check if the controller exported to index file only once: 1961ms
• cloneExampleFromGitHub (SLOW) extracts project files: 1869ms
• lb4 relation updates property decorator when property already exist in the model: 1566ms
• lb4 relation HasOne rejects relation when source key already exist in the model: 1362ms
• lb4 relation HasOne Execute relation with existing relation name rejects if the relation name already exists in the repository: 1344ms
• lb4 relation HasMany Execute relation with existing relation name rejects if the relation name already exists in the repository: 1325ms
• lb4 relation rejects relation when destination model doesn't have primary Key: 1320ms
• tsdocs runs api-extractor: 1280ms
• lb4 relation HasMany rejects relation when source key already exist in the model: 1254ms
• lb4 copyright with git updates copyright/license headers with options: 1239ms
• lb4 copyright for monorepo updates copyright/license headers: 1205ms
• build compiles ts files: 1046ms
• Application rejects division by zero with 412 error: 1022ms

Nice to have

• Investigate why are lb4 relation tests so slow. Do they have expensive setup? Can we find a more efficient way how to test the relation generator?

[dhmlau]

@bajtos, given the long list, I'm thinking this might be better to turn this issue as an epic so that we can estimate on the smaller tasks. WDYT?

[bajtos]

@dhmlau

given the long list, I'm thinking this might be better to turn this issue as an epic so that we can estimate on the smaller tasks.

Sure, I am fine to convert this story into an epic.

I think the first two items have been already solved by https://github.com/strongloop/loopback-next/pull/5721. Can you @raymondfeng please confirm?

Most of the remaining items are for relation tests. I think it would be best to do a short spike to find out the root cause and then decide how to plan the follow-up work. I opened a new GH issue for the spike - see https://github.com/strongloop/loopback-next/issues/6017

Besides lb4 relation tests, there are also:

• cloneExampleFromGitHub (SLOW) extracts project files: 1869ms
• lb4 copyright with git updates copyright/license headers with options: 1239ms
• lb4 copyright for monorepo updates copyright/license headers: 1205ms
• build compiles ts files: 1046ms
• Application rejects division by zero with 412 error: 1022ms

Maybe we can create another spike for lb4 copyright?