code coverage error for LoggerEngineDataSelector.cls upon deployment

[heapallocation]

Package Edition of Nebula Logger

Unlocked Package

Package Version of Nebula Logger

v4.12.9

New Bug Summary

Hi there,

I have installed the unlocked pkg in sandbox and am attempting to deploy to a prod. env. using the metadata api. I am getting a code coverage error on the LoggerEngineDataSelector.cls (screenshot below) when running the apex tests as part of the deployment. Could the code coverage please be increased if the error that I am getting is correct?

Thanks!
John.

[jongpie]

Hi @heapallocation - when you're deploying, are you deploying your own metadata? Or are you including the class LoggerEngineDataSelector in your deployment? That class is difficult to get full code coverage in some environments because some of the queries don't work in all Salesforce orgs - but I haven't previously seen this cause any deployment issues.

[mGrad10]

I'm having a similar issue. I'm attempting to manually install (not using unlocked or managed) just the core directory in my org, but I'm getting code coverage errors on the following classes:

1. LoggerFieldMapper - 69%
2. LoggerEngineDataSelector - 69%

I did include LoggerFieldMapper_Tests and LoggerEngineDataSelector_Tests in my deployment.

Are there other tests I should include that are not in core?
I thought I might need to include the extra-tests directory, however the README advises against installing this when not using the unlocked or managed.

Any advice is appreciated, thank you!

[jongpie]

@mGrad10 is this issue happening for you when deploying to a production org? And when deploying, are you only deploying Nebula Logger's core directory?

The current challenge with those 2 classes is that some functionality can't be tested in some orgs. For example, theLoggerEngineDataSelector_Tests has some tests related to Community/Experience Cloud sites, but those tests are skipped in orgs without Experience Cloud enabled, which lowers the code coverage. There might be a way for me to adjust some of the tests to improve coverage, but it will be impossible to get full coverage on the tests in all orgs unfortunately. And yeah, I definitely don't recommend deploying the extra-tests directory, at least for now - it includes a lot of metadata that is unnecessary/just for testing, and some of the metadata could break your own code in your org.

And just out of curiosity, what was your reason(s) for deploying the core metadata, instead of using the unlocked package? That approach is perfectly fine to use (other than the code coverage issues you're having 😅 ), but I'm always curious to hear people's thoughts behind deploying the metadata yourself (instead of using one of the packages).

[mGrad10]

@jongpie Thanks for such a quick response! To answer your qqs:

1. This is happening when trying to validate a deployment containing only the metadata in nebula-logger/core targeting a dev sandbox.
2. We do have Experience sites in the target dev sandbox
3. Unfortunately, for our use case we're not able to use the unlocked package, however I have tested it in a different dev sandbox and it's very nice! I wish we could use unlocked, but alas we need to manually install.

As mentioned, I do have the unlocked version in a different sandbox with Experience sites. So, I ran LoggerEngineDataSelector_Tests and LoggerFieldMapper_Tests in there. Here's what I'm seeing....

1. LoggerEngineDataSelector.getNetworkProxies() and LoggerEngineDataSelector.getCachedNetworkProxy() are not covered
2. LoggerFieldMapper.mapFieldValues() in the block where you're creating a LogMessage is not covered
3. LoggerFieldMapper.loadRecords() the block inside the for loop is not covered.

Since both my sandboxes have Experience Sites, is it possible I'm missing something? or are these just not able to be covered?

Sincerely appreciate all your help, we love Nebula and very excited to use it.

[jongpie]

@mGrad10 thanks so much for all the info! Knowing exactly which methods are missing coverage in your org is incredibly helpful, thanks for providing that info.

• I'll have to look into those LoggerEngineDataSelector methods & their tests some more to see why they're not being covered (especially since you do have Experience sites in your sandbox).
• For LoggerFieldMapper.loadRecords(), that doesn't have code coverage out-of-the-box because there aren't any LoggerFieldMapping__mdt records include with Nebula Logger. I'll see if there's a way to change some of the code or tests to ensure that code block is covered.

When you're deploying, are you using the sf CLI for the deployment? If so, could you share the command that you're using (including any flags/parameters)? I'd like to change Nebula Logger's pipeline to also fail when one of the classes has less than 75% code coverage - right now, I'm using sf project deploy start, without running tests (the tests run later in the pipeline, using a different command). I think I probably need to use something like sf project deploy start --test-level RunLocalTests, but I'd love to know how you're doing it when you get these errors.

[mGrad10]

@jongpie
I am using the following command to validate:

sf project deploy validate --manifest manifest/myManifest.xml --target-org myTargetOrgAlias --test-level RunSpecifiedTests --tests big long list of tests space separated

• To create my manifest I just added core to a new project in VSCode, right click the directory and generate manifest

• I got the list of tests from your test suite in nebula-logger/core/tests but I had to add LogEntryEventStreamController_Tests. Unfortunately, we have to list these out since sf doesn't allow us to specify a path to a test suite.

Regarding the LoggerFieldMapper.loadRecords()

EDITED since I looked into the code more....see next comment......

Hope this helps, I sincerely appreciate all your help, and quick responses!

[mGrad10]

@jongpie

I looked into LoggerFieldMapper.loadRecords() here's a few things I'm seeing, curious what you think.....

1. I see in your test methods in LoggerFieldMapper_Tests, you are using a mock LoggerFieldMapping__c MDT to populate the LoggerFieldMapper.SOURCE_OBJECT_TYPE_TO_TARGET_FIELD_MAPPINGS property.
2. Your test methods call LoggerFieldMapper.mapFieldValues() which uses SOURCE_OBJECT_TYPE_TO_TARGET_FIELD_MAPPINGS however, this doesn't call loadRecords() -- I believe that's only called when the class is loaded.

I'm wondering if we can replace the MDT query in loadRecords() with a new property and mock following the same pattern?

Also, can you help me understand the purpose of the LoggerFieldMapping__c MDT? is this allowing us to specify fields on LogEntryEvent__e we want to map to other SObject fields?

[jongpie]

Hi @mGrad10 thanks for all of the info!

For the sf command: I think I can update part of Nebula Logger's pipeline to run tests during the pipeline's deployment (similar to your command), which should then cause the pipeline to (intentionally) fail. That'll then force me to make sure all the classes in the core folder have 75%+ code coverage to avoid this issue in the future for anyone like you that wants to deploy the core folder (instead of using one of the packages).

For the LoggerEngineDataSelector class: even though you have Experience sites enabled in your org, you're not getting code coverage for those queries because at the moment, those relevant tests are in a separate class, LoggerEngineDataSelector_Tests_Network that's only used in the pipeline

• I think I one point, having those tests in a separate file in extra-tests tests was once necessary - but since then, other changes have been made to the codebase, and I think I can move those test methods into the main LoggerEngineDataSelector_Tests test class now. That will then help with code coverage in LoggerEngineDataSelector_Tests (and more importantly, then I can delete LoggerEngineDataSelector_Tests_Network, which I always forget exists, so it'll be easier to maintain all the tests in just LoggerEngineDataSelector_Tests)

For the LoggerFieldMapper class: I had started working on introducing a new class LoggerConfigurationDataSelector a few months ago so that the LoggerFieldMapping__mdt query (and a few other similar queries in other Apex classes) could be mocked, but... I guess I never finished that work 😅 That will eliminate some of those issues in LoggerFieldMapper.loadRecords()

• I'll revisit the LoggerFieldMapper class & tests to introduce mock query results, which will then help with code coverage in LoggerFieldMapper_Tests (and more importantly, it'll improve the overall quality of the tests in LoggerFieldMapper_Tests 🥳).

As far as the purpose of LoggerFieldMapping__mdt, it's part of a relatively new feature for people that want to add their own custom fields to one of Nebula Logger's objects.

• The original issue Add support for setting custom fields in LogEntryEventBuilder class #655 has some great context & examples, but the summary is that for some orgs/projects/requirements, people need to be able to track (and report on) certain pieces of data, and none of Nebula Logger's provided fields work for their purposes.
• As of release v4.13.14, Nebula Logger now has a built-in/official way to add & set your own custom fields on its objects.
• Currently, only custom fields on LogEntryEvent__e, Log__c, LogEntry__c, and LoggerScenario__c are supported
  • ➡️ To map a custom field on LogEntryEvent__e and have it stored on a custom object, you can create LoggerFieldMapping__mdt records with the mappings
• Currently, setting custom fields works in Apex (release v4.13.14) and lighting components (release v4.14.6)
  • There's an open issue to add equivalent functionality for Flow logging - issue Add support for custom field mappings in Flow #719