changed build.yml to use LoggerCore test suite for code coverage sent…

… to codecov.io

.github/codecov.yml

@@ -21,17 +21,3 @@ ignore:
   - 'nebula-logger/recipes/**/*'
 comment:
   behavior: new
-# https://docs.codecov.com/docs/flags
-# flags:
-#   core:
-#     paths:
-#       - 'nebula-logger/core/**/*'
-#     carryforward: false
-#   Apex:
-#     paths:
-#       - 'nebula-logger/core/**/*.cls'
-#     carryforward: false
-#   LWC:
-#     paths:
-#       - 'nebula-logger/core/**/*.js'
-#     carryforward: false

.github/workflows/build.yml

@@ -182,8 +182,8 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
-      # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
+      # This data is also mocked during tests, but running the Apex tests sync & async serves within the pipeline acts as an extra level of
+      # integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Synchronously'
         run: npm run test:apex:nocoverage -- --synchronous
 
@@ -250,29 +250,13 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
-      # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
+      # This data is also mocked during tests, but running the Apex tests sync & async serves within the pipeline acts as an extra level of
+      # integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Synchronously'
         run: npm run test:apex:nocoverage -- --synchronous
 
-      # For all other Apex test runs in the pipeline, test:apex:nocoverage is used
-      # because the code coverage results aren't needed/used, and the test runs & retrievals
-      # can be a little faster when code coverage is disabled.
-      #
-      # This difference in how tests run only happens here for the base scratch org
-      # to validate that tests work correctly - and provided sufficient code coverage -
-      # in orgs that do not have some optional Salesforce features that are referenced by Nebula Logger
-      # (e.g., orgs without Experience Cloud, OmniStudio, Platform Cache, etc.)
       - name: 'Run Apex Tests Asynchronously'
-        run: npm run test:apex
-
-      # This is the only scratch org that's used for uploading code coverage
-      - name: 'Upload Apex test code coverage to Codecov.io'
-        uses: codecov/codecov-action@v4
-        with:
-          fail_ci_if_error: true
-          flags: Apex
-          token: ${{ secrets.CODECOV_TOKEN }}
+        run: npm run test:apex:nocoverage
 
       - name: 'Delete Scratch Org'
         run: npx sf org delete scratch --no-prompt
@@ -334,8 +318,8 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
-      # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
+      # This data is also mocked during tests, but running the Apex tests sync & async serves within the pipeline acts as an extra level of
+      # integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Synchronously'
         run: npm run test:apex:nocoverage -- --synchronous
 
@@ -405,8 +389,8 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
-      # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
+      # This data is also mocked during tests, but running the Apex tests sync & async serves within the pipeline acts as an extra level of
+      # integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Synchronously'
         run: npm run test:apex:nocoverage -- --synchronous
 
@@ -480,8 +464,8 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
-      # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
+      # This data is also mocked during tests, but running the Apex tests sync & async serves within the pipeline acts as an extra level of
+      # integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Synchronously'
         run: npm run test:apex:nocoverage -- --synchronous
 
@@ -548,8 +532,8 @@ jobs:
       # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
       # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
       # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
-      # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session.
+      # This data is also mocked during tests, but running the Apex tests sync & async serves within the pipeline acts as an extra level of
+      # integration testing to ensure that everything works with or without an active session.
       - name: 'Run Apex Tests Synchronously'
         run: npm run test:apex:nocoverage -- --synchronous
 
@@ -660,16 +644,32 @@ jobs:
       - name: 'Create & Install Package Version'
         run: npx pwsh ./scripts/build/create-and-install-package-version.ps1 -targetpackagealias '"Nebula Logger - Core"' -targetreadme ./README.md -targetusername nebula-logger-package-demo
 
-      # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session.
-      # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously.
-      # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously).
-      # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with.
-      # Running the Apex tests sync & async serves as an extra level of integration testing in the meantime to ensure that everything works with or without an active session.
-      - name: 'Run Apex Tests Synchronously'
-        run: npm run test:apex:nocoverage -- --targetusername nebula-logger-package-demo --synchronous
+      # This is the only place in Nebula Logger's pipeline where the `LoggerCore` test suite runs & the results are sent to Codecov.io.
+      # This is specifically done in the base scratch org, using only the `LoggerCore test` suite, in order to help validate that the core metadata
+      # provides sufficient code coverage for teams that deploy Nebula Logger's metadata directly to their org, instead of installing one of Nebula Logger's 2GP packages.
+      #   1. Many teams cannot use one of the 2GP packages for various reasons, including company policies, security concerns, etc.,
+      #      and being able to deploy the core metadata is something that should be supported.
+      #   2. And even though the pipeline runs the `extra-tests` directory to validate logging works correctly in various types of scratch orgs,
+      #      for teams that are trying to deploy Nebula Logger's metadata, it's critical that the core tests have
+      #      sufficient code coverage to be deployed to a prod org.
+      #       - In the past, this has not always been the case, resulting in some teams having deployment issues & project delays due to the low code coverage
+      #         that was (formerly) provided by some of the core tests classes.
+      #       - In orgs that do not have some optional Salesforce features enabled/available (e.g., orgs without Experience Cloud, OmniStudio, Platform Cache, etc.),
+      #         the code coverage can be especially low, so using the base scratch org acts
+      #
 
-      - name: 'Run Apex Tests Asynchronously'
-        run: npm run test:apex:nocoverage -- --targetusername nebula-logger-package-demo
+      # So now only the core test suite's results, from a base scratch org, are used for reporting code coverage, even though the project's overall code coverage
+      # is much higher when using the `extra-tests` directory.
+      - name: 'Get Core Test Suite Code Coverage'
+        run: npm run test:apex:suite:core
+
+      # This is the only scratch org that's used for uploading code coverage
+      - name: 'Upload Apex test code coverage to Codecov.io'
+        uses: codecov/codecov-action@v4
+        with:
+          fail_ci_if_error: true
+          flags: Apex
+          token: ${{ secrets.CODECOV_TOKEN }}
 
       - name: 'Commit New Package Version'
         if: ${{ github.event_name == 'pull_request' }}

nebula-logger/core/tests/configuration/classes/LoggerConfigurationSelector_Tests.cls

@@ -40,9 +40,7 @@ private class LoggerConfigurationSelector_Tests {
 
   @IsTest
   static void it_returns_log_entry_data_mask_rules_from_provided_mocks() {
-    LoggerConfigurationSelector.mockLogEntryDataMaskRules = new List<LogEntryDataMaskRule__mdt>{
-      new LogEntryDataMaskRule__mdt(DeveloperName = 'SomeDevName')
-    };
+    LoggerConfigurationSelector.mockLogEntryDataMaskRules = new List<LogEntryDataMaskRule__mdt>{ new LogEntryDataMaskRule__mdt(DeveloperName = 'SomeDevName') };
 
     List<LogEntryDataMaskRule__mdt> returnedValues = LoggerConfigurationSelector.getInstance().getLogEntryDataMaskRules();
 
@@ -181,9 +179,7 @@ private class LoggerConfigurationSelector_Tests {
 
   @IsTest
   static void it_returns_logger_sobject_handlers_from_provided_mocks() {
-    LoggerConfigurationSelector.mockLoggerSObjectHandlers = new List<LoggerSObjectHandler__mdt>{
-      new LoggerSObjectHandler__mdt(DeveloperName = 'SomeDevName')
-    };
+    LoggerConfigurationSelector.mockLoggerSObjectHandlers = new List<LoggerSObjectHandler__mdt>{ new LoggerSObjectHandler__mdt(DeveloperName = 'SomeDevName') };
 
     List<LoggerSObjectHandler__mdt> returnedValues = LoggerConfigurationSelector.getInstance().getLoggerSObjectHandlers();
 

package.json

@@ -66,7 +66,7 @@
     "test": "npm run test:lwc && npm run test:apex",
     "test:apex": "npm run test:apex:nocoverage -- --code-coverage --detailed-coverage",
     "test:apex:nocoverage": "npx sf apex run test --concise --test-level RunLocalTests --wait 30 --result-format human --output-dir ./test-coverage/apex",
-    "test:apex:suite": "npx sf apex run test --concise --suite-names LoggerCore --wait 30 --result-format human --code-coverage --detailed-coverage --output-dir ./tests/apex",
+    "test:apex:suite:core": "npx sf apex run test --concise --suite-names LoggerCore --wait 30 --result-format human --code-coverage --detailed-coverage --output-dir ./test-coverage/apex",
     "test:lwc": "sfdx-lwc-jest --skipApiVersionCheck --coverage",
     "test:lwc:nocoverage": "sfdx-lwc-jest --skipApiVersionCheck",
     "test:nocoverage": "npm run test:lwc:nocoverage && npm run test:apex:nocoverage"