7

Typically, if I want to verify the callout is made and there may be asynchronous processing involve, I just track it on my mock. class MyMock implements HttpCalloutMock { Integer calls = 0; public HttpResponse respond(HttpRequest request) { calls++; // mock implementation here } } Then, in your test, you just cache your mock ...


6

In your query, Id = :WorkOrder.Id should be Id = :fieldVisit.Id The binding operator works with a record not with SObjectType. // WorkOrder.Id returns field API name as Schema.SObjectField data type // this is used mainly with dynamic apex // where as query filter expects a primary data type Schema.SObjectField Id = WorkOrder.Id;


6

Any unit test you ever run in Salesforce will roll back all DML Operations at the end of the transaction. Same with emails sent out. Unit tests do not persist any change to your org, other than incrementing auto-number fields unless you configure them to avoid it. See, for example, from Add a Test Class in the Apex Developer Guide (emphasis mine): The ...


6

This is subtle... If I write an object to implement the ShopBackend interface, there's no requirement that this object chooses the same parameter names as the interface. It only has to match the signature in terms of types and order. So, I can quite happily write public class ShopFoo implements ShopBackend { public void initialize() { } public ...


5

The solution for this is to move the queries into a Selector layer and then use dependency injection to use a mock selector during testmethods rather than the PROD selector when running normally Now I am a particular fan of the fflib pattern and ApexMocks (which exploits the StubApi) for doing all this but there are other approaches that accomplish the same ...


5

Nor average, neither sum of percents. If some test methods cover one line of code twice, it only means that this exact line of code is covered. So the actual test coverage is linesCovered / allLines * 100. Example: imagine 1st test class covers one method in your controller (30%), 2nd test class covers 2 methods including the previous mentioned one (50%), ...


4

CronTrigger behaves like, for example, User in unit test context - that is, it's treated as a metadata object which is visible inside test isolation. That makes writing assertions against it more challenging, because you're always vulnerable to org data state. One approach you can apply here is to snapshot the count prior to invoking your Schedulable: ...


4

I'm aware of two approaches that allow you to mock system objects like these that (depending on the system objects involved) can be used individually or together: Provide a "Plain Old Apex Object" with equivalent properties to the system object and isolate the actual access to the real system objects in a small accessor object exposing the "POAO" analogues ...


4

Honestly, you make assertions for a method that returns void the same way you write assertions for anything else you're testing. Assertions are about validating the results of running a piece of code. If your method is inserting a record, assert that you have one more record after running the code compared to before (query before and after) If your method ...


4

Simply create an instance of inner class and populate its properties by test data: OuterClass.ExistingAccountResult result = new OuterClass.ExistingAccountResult(); result.salesforceaccountid = // testId result.status = // testStatus result.includeinfunnel = // testData result.masterid = // testId result.accountid = // testId


4

The community user should have access to Loan_Doc_Sort__c record to upload files on it. You have few options, Change the OWD of Loan_Doc_Sort__c to public read-only external Create a manual share record for Loan_Doc_Sort__c after insert and share it with the commnunity user. Ensure The community user is the one creating the Loan_Doc_Sort__c in the test ...


4

In general, if you have a framework which allows you to bypass triggers for test data setup, you should do it. My primary argument for doing so is that Unit Tests should test individual units. These tests should be atomic. If you are testing how some AccountService functionality works, that test should not be dependent in any way on what logic is in your ...


4

This isn't a coverage problem; it's a logic problem. Your test is failing, and you only get coverage for tests that pass. It appears to me on a quick read that your problem is the JSON with which you seed your Mock does not match your code's expectations. You are setting the required field Account.Name via acc.Name=String.valueOf(results.get('Test'...


4

You have to query back the opportunity in order to see the value of the field. Since the value you are showing on the debug shows the value contained in the variable testOpportunity and not the value of the opportunity stored in memory(which was modified by the trigger). add a line after the update to update the value of the variable with the value stored ...


4

Well this is a great find. Lots of undocumented / poorly documented behavior as far as I can tell :p. First, I verified on my end that I also am now receiving a job id in tests. I modified your unit test to verify that this happens both inside and outside of a Test.start/stop context. In both cases, we are now receiving job ids. @isTest public class ...


4

When methods are not marked static, you have to first instantiate the class. In this case, you have to write it like this: votingRelationHandler handler = new votingRelationHandler(<pass your records here>); handler.company_voting_member(); UPDATE: I see you updated your original code and my answer is no longer answering your question. Your ...


4

In unit tests, you generally make assertions on the output and the result of running a piece of code. Given the name of the thing you're testing (Chatlog.deleteLog()), I'd assume there is a chat log you should be deleting. You want to assert that the intended log is actually deleted (done by querying before and after running the target piece of code) if ...


4

No, it does not. Apex test coverage is calculated as the percentage of lines covered out of total executable lines. The class OpportunityStageNames contains no executable lines of code, so it cannot be covered, and its lines do not contribute to the denominator of the fraction (lines covered)/(total executable lines) across any defined subset of your Apex ...


4

This is a classic problem with testing multi-layer Asynchronous Apex. The trick is that Test.startTest() and Test.stopTest() only force synchronous execution of the first layer - in this case, the future method - of asynchronous code. Any asynchronous functionality enqueued by that layer will ultimately execute, and may in fact be visible in your debug ...


4

You should not be calling the deleteDuplicates method from within the for loop. for (Patch_Panel__c p : param2) { PatchPanelTriggerClass.deleteDuplicates(p.Name); // Class.PatchPanelTriggerClassTestBatch.execute: line 19, column 1 I suggest you either change the calling code or else accept the collection in deleteDuplicates and modify the SOQL to use ...


4

Your outer class is PT_Interface, so you need to call your inner class in this format PT_Interface.PT_Request_Model. And you can't call your constructor without a parameter since you have defined your constructor to expect a parameter. Sample code: PT_Interface.PT_Request_Model ic = new PT_Interface.PT_Request_Model(anObject); ic.requestBody('a01234567');


3

As error says List starts with [ and ends with ]. Also I notice extra } inside the array. Try below in test class: string str = '[{"attributes":{"type":"nForce__Session__c","url":"/services/data/v45.0/sobjects/nForce__Session__c/0039000001QYYa4AAH"},"Id":"0039000001QYYa4AAH","Name":"Burlington Textiles Corp of America"}]'; NOTE: For understanding better, ...


3

You have to create your own test data. This line assumes you can split a string before checking if it is null: Set<String> readOnlyprofiles = new Set<String>(Integration__c.getOrgDefaults().Account_Name_Read_Only_Profiles__c.split(',')); Instead, you must either add a null check, or have your test actually create this custom setting record. ...


3

Your problem is here: Integration__c.getOrgDefaults(). Custom Settings are considered data for the purposes of Apex testing, ie, there aren't any unless you insert them. So getOrgDefaults() returns a null, and trying to get a field value and split() it throws the NullPointerException. Insert an org defaults record for the Integration__c custom setting ...


3

Inline Apex tests, where the unit tests are included in the body of the class being tested, have not been allowed on Salesforce since API version 28.0. You should not create or deploy new code on API 28.0, which is ~6 years old at this point. By doing so, you're buying into six years of old bugs and behaviors that have long-since changed, and locking ...


3

There was a point in time where Salesforce allowed test methods to be defined in the same class as the actual code, but that point in time ended about 6 years ago. From Apex Test Code Segregation on the official Salesforce blogs Starting with the Summer ’13 release of the platform, Apex test methods need to be created in test classes. (A “test class” is ...


3

I can see the benefits of the CustomMetadataDAO approach from the comments above, but I tend to go a bit more direct. Since custom metadata records stay the same for a whole transaction, I tend to make them static, TestVisible, and lazy-instantiated. e.g. @TestVisible private static List<Degree_Offering__mdt> degreeOfferingMetadata {get { if(...


3

https://corevalue.net/code-coverage-for-custom-metadata-based-decisions/ You could essentially create a class to handle the querying of all your custom metadata and a test class for it that would allow you to create the records you want the query to return if need be. This class would check a map variable you set in test execution to see if there's a ...


3

Don't worry, You're Doing It Right. Unit tests are almost always larger than the code they're testing, assuming you're doing actual unit tests, and not just smoke tests, because you need to check a lot of conditions in order to make sure everything is working correctly. Unit testing comes in three phases: setup, test, and validation. In the setup phase, you ...


3

The reason of the given error message is that maximum amount of unit tests executions per 24 hours is reached. According to the documentation: The maximum number of test classes you can run per 24-hour period is the greater of 500 or 10 multiplied by the number of test classes in the org. For sandbox and Developer Edition organizations, this limit ...


Only top voted, non community-wiki answers of a minimum length are eligible