search

jongpie / NebulaLogger

The most robust observability solution for Salesforce experts. Built 100% natively on the platform, and designed to work seamlessly with Apex, Lightning Components, Flow, Process Builder & integrations.
https://nebulalogger.com
MIT License
705 stars 165 forks source link

code coverage error for LoggerEngineDataSelector.cls upon deployment #687

Open heapallocation opened 5 months ago

heapallocation commented 5 months ago

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.

Screenshot 2024-05-13 at 10 06 02 AM

jongpie commented 5 months ago

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 commented 2 months ago

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 commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

@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.

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 commented 2 months ago

@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

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 commented 2 months ago

@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 commented 2 months ago

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

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()

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.