function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
carloecarloe 

Apex test - other triggers pulling the score down

Hi there,

We're have written an apex controller for vfp and the test coverage is 100%. However the average across all class/trigger is only at 55% because of some Triggers pulling it down. Is there a way we could exclude these triggers from being fired in our test class?

 

Best Answer chosen by Admin (Salesforce Developers) 
SamuelDeRyckeSamuelDeRycke

I don't think you really want to exclude your triggers and their lack of test coverage. You should really aim to have test covering them, so that you'll know when certain changes break some of the custom code.

 

The reason your soql statement is not returning values, is because by default your data is shielded off. You can overwrite this behavior by using the @IsTest(seealldata=true) annotdation. But, I believe you're trying to solve the symphtoms rather than the disease. What is stopping you to have those triggers properly covered by test code ?

 

 

All Answers

bob_buzzardbob_buzzard

The issue here isn't that the triggers are being fired from your test class, its that the code coverage report considers all classes and triggers rather than just those that your test class touches.  If you run all tests for your org, you'll get a proper view of the coverage across all code.

carloecarloe

Thanks Bob.

 

I've run all test and the average was 71%.

 

Basically here's the summary of our situation:

1. The controller (@100%) we are testing accepts certain values coming from the Account and Asset object. If the values from both objects are valid, it goes to a pagereference. This controller does not insert any records into the system.

 

2. In our test controller, we wrote our code to prepare our data by creating a test account and asset. Because of this, two triggers (17% and 46%) are being fired which is causing the low average. These triggers are for an Asset (after update/insert).

 

3. We figure we could bypass the trigger by not inserting records in the testmethod and instead use a fixed value (email) to query the Account and Asset (name). Afterall, the controller we are trying to deploy wont be inserting any records so there is no need to 'prepare' a test data. However, for some reason when we run the test we get : System.QueryException: List has no rows for assignment to SObject as if the account does not exists. We know for a fact that this account currently exists in this org and in production.

 

I know it's not a good practice to hardcode values but this is the only way we could think of to prevent the asset trigger from being fired.

 

Any advice?

 

 

SamuelDeRyckeSamuelDeRycke

I don't think you really want to exclude your triggers and their lack of test coverage. You should really aim to have test covering them, so that you'll know when certain changes break some of the custom code.

 

The reason your soql statement is not returning values, is because by default your data is shielded off. You can overwrite this behavior by using the @IsTest(seealldata=true) annotdation. But, I believe you're trying to solve the symphtoms rather than the disease. What is stopping you to have those triggers properly covered by test code ?

 

 

This was selected as the best answer
carloecarloe

Hi Sdry,

Our post was just seconds apart so not sure if you saw my last message.

 

See my previous message why we need to exclude the triggers.

 

Thanks!

SamuelDeRyckeSamuelDeRycke

I saw your post and had already updated my own. 

 

I disagree, you should aim for full test coverage on your triggers, both covering all lines, and all logical possible outcomes. Nor should you try to bypass this by creating data dependencies in your tests.  Unless you can give us a real argument to why you can not test those triggers.

 

 

carloecarloe

Hi Sdry,

 

Thank you for the tip, we'll try that.

 

The reason for not including that in the test is because the controller that we are trying to deploy will only validate values that are already in the system. It will not create any account/asset record in the system. The controller is used in a visualforce page which accepts two inputfields only.

 

Unfortunately the two triggers that are causing us the issue is responsible for an external integration. Our accounts and assets are integrated from another system and the trigger's function is to prevent any user from editing the record until the synchronization has been completed.

 

If we have to write a test account/asset in our testmethods, these triggers are fired and will result in low coverage. I feel that doing this is unnecessary given that the controller we are testing will not be doing this in production.

 

I hope that make sense :)

 

 

 

bob_buzzardbob_buzzard

While you should always aim for 100% test coverage on everything, pragmatism has to rear its ugly head from time to time.  Its not possible with web service callouts for example. Triggers only have to have 'some coverage', so SFDC will just enforce the coverage is not zero.

 

Bottom line is, if its your system you can do what you like with it - all we can do is advise best practice.

carloecarloe

Thanks for all your advice. I appreciate it :)