fix(legacy-tooling): use the 'targets' argument to override usual test file path

[sreenara]

COMPLETES # NA

This pull request addresses

The inability to run test files separately. Currently, the test:unit or test:integration command collects all test files for a package and runs them even though we try mentioning the test file names using commands such as this:
yarn workspace @webex/internal-plugin-dss test:unit -- test/unit/spec/dss.ts

Due to this, it is difficult to add .only() to tests and run them separately to troubleshoot problems.

by making the following changes

The run-tests script takes an argument targets which overrides the traditional test file collection.
In this PR, I've enhanced the Package class to consider the targets argument and collect only the file that has been mentioned as a target. This ensures that the tooling runs only the tests we want them to.

Change Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Tooling change
• Internal code refactor

The following scenarios where tested

1. Ran the command yarn workspace @webex/internal-plugin-dss test:unit --targets dss.ts

$ yarn workspace @webex/internal-plugin-dss test:unit --targets dss.ts
 PASS  test/unit/spec/dss.ts
  plugin-dss
    DSS
      #register()
        ✓ registers correctly (6 ms)
        ✓ rejects when it cannot authorize (4 ms)
      #unregister()
        ✓ unregisters correctly (3 ms)
        ✓ handles unregister when it is not registered (2 ms)
      #lookupDetail
        ✓ calls _request correctly (2 ms)
        ✓ works correctly (4 ms)
        ✓ fails correctly if lookup fails (3 ms)
        ✓ fails with default timeout when mercury does not respond (4 ms)
        ✓ does not fail with timeout when mercury response in time (5 ms)
      #lookup
        ✓ calls _request correctly (2 ms)
        ✓ calls _request correctly with entityProviderType (2 ms)
        ✓ works correctly (3 ms)
        ✓ fails correctly if lookup fails (2 ms)
        ✓ calls _batchedLookup correctly (2 ms)
        ✓ calls _batchedLookup correctly with entityProviderType (2 ms)
        ✓ Single batched lookup is made after 50 ms and works (3 ms)
        ✓ Single batched lookup fails correctly if lookup fails (3 ms)
        ✓ Batch of 2 lookups is made after 50 ms and works (5 ms)
        ✓ Batch of 2 lookups is made after 50 ms and one fails correctly (3 ms)
        ✓ Two unrelated lookups are made after 50 ms and work (3 ms)
        ✓ Two unrelated lookups are made after 50 ms and one fails correctly (3 ms)
        ✓ fails with default timeout when mercury does not respond (2 ms)
        ✓ does not fail with timeout when mercury response in time (3 ms)
      #lookupByEmail
        ✓ calls _request correctly (2 ms)
        ✓ works correctly (2 ms)
        ✓ fails correctly if lookup fails (2 ms)
        ✓ fails with default timeout when mercury does not respond (3 ms)
        ✓ does not fail with timeout when mercury response in time (2 ms)
      #search
        ✓ calls _request correctly (2 ms)
        ✓ works correctly (3 ms)
        ✓ fails with default timeout when mercury does not respond (2 ms)
        ✓ does not fail with timeout when mercury response in time (3 ms)
        ✓ fails with timeout when request only partially resolved (3 ms)
      #_request
        ✓ handles a request correctly (2 ms)
        ✓ handles a request with foundPath correctly (3 ms)
        ✓ handles a request with foundPath and notFoundPath correctly (2 ms)
      #_batchedLookup
        ✓ calls batcher.request on new batcher for first lookup (3 ms)
        ✓ calls batcher.request on new batcher for lookup with new resource (4 ms)
        ✓ calls batcher.request on existing batcher for lookup with existing reource (3 ms)
        ○ skipped fails fails when mercury does not respond, later batches can still pass ok
      #searchPlaces
        ✓ calls _request correctly (3 ms)
        ✓ works correctly (2 ms)

Test Suites: 1 passed, 1 total
Tests:       1 skipped, 41 passed, 42 total
Snapshots:   0 total
Time:        1.024 s

2. Tested the same with integration tests and observed the same behavior.

I certified that

• I have read and followed contributing guidelines

• I discussed changes with code owners prior to submitting this pull request

• I have not skipped any automated checks

• All existing and new tests passed

• I have updated the documentation accordingly

---

Make sure to have followed the contributing guidelines before submitting.

[arun3528]

code looks good , need the intergation and coverage to be fixed

[sreenara]

These tests are fixed now.

[mkesavan13]

Looks good. Can we update the CONTRIBUTING also to mention how to use it?

[sreenara]

Looks good. Can we update the CONTRIBUTING also to mention how to use it?

@mkesavan13 If we add the --help argument to the command we will get the options anyway. Is it necessary to update the CONTRIBUTING as well?

$ yarn workspace @webex/internal-plugin-dss test:unit --help
Usage: index test [options]

Test a legacy package

Options:
  --automation                         Run automation-scoped tests.
  --documentation                      Run documentation-scoped tests.
  --integration                        Run integration-scoped tests.
  -browsers, --karma-browsers <array>  Browsers to use when running Karma tests. (default: ["chrome","firefox"])
  -debug, --karma-debug                Run Karma in debug mode
  -port, --karma-port <string>         Port to run the Karma server on
  --runner <array>                     Test runner to use.
  --targets <string>                   Override the default test target for reading files.
  --unit                               Run unit-scoped tests.
  -h, --help