Starting from the top with "how-things-work-now", and specifically using the processes bridge component of the process reporter module:
1. The processes bridge unit tests are included via the "all-tests.html" file within universal's web-based tests folder, i.e.:
2. The web page for the processes bridge unit tests referenced in "all-tests.html" is "ProcessesBridgeTest.html" and is found inside the "processReporter" web test directory:
3. "ProcessesBridgeTest.html" loads the actual unit tests from the script file "ProcessesBridgeTests.js":
4. In addition to defining unit tests for each of the functions in the "processesBridge.js" source file, "ProcessesBridgeTests.js" defines a function gpii.tests.processes.runTests(). This is called from "ProcessesBridgeTest.html":
When the above configuration is run as part of npm run test, the code coverage for "processesBridge.js" is 25-30% as shown in the second row of the report:
The above setup was modified such that processes bridge unit tests were run using node. This is shown in the "ProcessReporterMoreCoverage" branch. The steps to make the change were are as follows.
1. Remove the reference to "ProcessesBridgeTest.html" from "all-tests.html":
2. Delete the "ProcessesBridgeTest.html" file from the "ProcessReporter" web test directory:
3. Move the unit tests in "ProcessesBridgeTests.js" out of the "web" test directory up to the "test" directory, and add necessary require(...) statements such that it can be run using node. Also, a call to the gpii.tests.processes.runTests() function was added to the end of the script. Except for these changes, the unit test definitions themselves remain the same:
4. Modify the "all-tests.js" file within universal's "tests" directory to reference the "ProcessesBridgeTests.js" unit tests:
When the above configuration is run as part of npm run test, the coverage report shows approximately 90% coverage (second row):
Why the difference in coverage for the same tests? (My guess is that not all the tests are run in the web-based setup).
(Aside: note that the coverage for other process reporter related tests, namely "ProcessReporter.js" stays the same for both scenarios at about 50%. SInce nothing was changed in terms of how its unit tests were run, that non-result was expected).