New answers tagged

2

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


0

One possible cause for this would be test context not finding data initialized in @TestSetup Here is one small change I would do and retry this, static void allCaseDetails() { Id testContact = [SELECT Id FROM Contact LIMIT 1].Id; // Query explicitly here so data is found in the context List<Case> lstcases = [Select Id, Subject, ContactId,...


1

Your query should fail. You can't execute Apex statements in dynamic SOQL: '... Implied_Consent_Expiry__pc.date() <= system.today() ...' You can't even do the part on the left without causing issues, as you'd have to use a date formula, not just arbitrary Apex. Also, your batch could be optimized to process fewer records by changing your filters. ...


2

Mocks do not replace the need to create and insert appropriate test data to ensure your code executes the logic path you are aiming to test. Here, your unit test code must create and insert a ExtCred__c record that meets the expectations of your code under test. Additionally, you should use Schema methods like getRecordTypeInfosByDeveloperName() to ...


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


0

So, best practice is to never put hard-coded IDs into Apex, PBs, or Flows. In our org, any pull request that includes hard-coded IDs is immediately sent back to the developer for change. What you want in this use case is for the Process Builder to delegate its work of finding and assigning the appropriate lookupId to either: Invocable Apex Lightning Flow ...


0

You should always try to avoid hardcoding record ids. It can be troublesome on sandboxes or, as you can see, in tests. You could consider moving the id from the process builder action into a custom setting which then can be referenced and created in sandboxes and test methods.


0

You need to do this in a single test. Data processed by one test method is not available to another. Each method has its separate transaction. Insert the test records. Schedule the job, after the startest(). Query the result and assert after the stopTest().


2

You don't write a unit test for classes like this. Only executable, non-debug, non-test, non-comment lines of code count for code coverage, so this class automatically has 100% code coverage.


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


1

If you are new to writing Apex tests start by working through these Apex Testing Trailhead units. Asynchronous logic is run when you call Test.stopTest(). So to test the batch job, in the unit test method(s): Insert some data suitable for the batch job Call Test.startTest Database.execute your batch job Call Test.stopTest Assert that the results are as ...


1

There are at least two serious bugs in this code. for (Property__c prop : propList) { if (prop.Escrow_Company__c != null) { accIds.add(prop.Escrow_Company__c); oppIds.add(prop.Opportunity__c); } Map<Id, Opportunity> opportunities = new Map<Id, Opportunity>([ SELECT Id, Name, ...


0

If you're using it exactly as written, your JSON isn't valid. { "clients": [ { "client_u_id": "cbfb020e-e50b-43ee-b912-c82d2f4dc45c", "company_id": xx, xx isn't a valid value. In that value, the JSON parser expects: 'STRING', 'NUMBER', 'NULL', 'TRUE', 'FALSE', '{', '[' If you create a valid payload, your error may ...


0

Hey @EvAzi this is the intended design: https://success.salesforce.com/ideaView?id=08730000000Dj51AAC Static vars are cleared before each test method, querying for the data from the testSetup method is the correct paradigm. We intentionally clear out static variables between each test method. If we did not, each test would cease to be an independent ...


1

I submitted an Idea for this to work, but I'm not sure we'll ever get to see it, unfortunately. For now, you need to re-query the records that were created during each unit test. testSetup's primary purpose is to reduce the time needed to start up each unit test by populating test records once before the tests start. You'll still realize a significant ...


1

I have investigated in more details and apparently, if you perform a relationship query and then display the result using System.debug() method, it will not display the related object's values in the log, even if those values are not null.


2

As per developer Guide The testMethod keyword is now deprecated. Use the @isTest annotation on classes and methods instead. The @isTest annotation on methods is equivalent to the testMethod keyword'. NOTE: testMethod doesn't have any impact on the count of apex character limit like it's mentioned in the other post the only thing here is that testMethod is ...


2

When unit testing triggers, is is customary to execute the trigger directly (you need this to get code coverage on the trigger itself). Since you already created the record, consider just cloning it and using that. Make sure you test both inserts and updates in different tests. @isTest static void testInsert(); voting_relation__c vr = [select ...


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


3

I think there are two linked misunderstandings here. I realized that my static boolean flag doesn't reset even though using both test.startTest() and System.runAs(User) to start a new context. Test.startTest() and System.runAs() both manipulate aspects of the transaction context: Test.startTest() resets your governor limits, and System.runAs() alters the ...


3

Most of your assumptions are fundamentally correct: you may mutate objects in Trigger.new without performing DML, and your updates will be persisted transparently. There appear to be two issues preventing your unit test class from behaving as expected. Your test setup includes no Opportunities associated with the Account. opps.size() will then always be ...


2

When you bypass trigger logic, you need to bookend your disablement. Typical flow is as below: @IsTest static void myTest() { // disable trigger // insert data // enable trigger Test.startTest(); // update data Test.stopTest(); // assert against behavior }


0

// This test class covered 100% code for Delete_Content_Document__e trigger @isTest public class DeleteContentDocumentTriggerTest { @testSetup static void createTestData() { Global_Settings__c globalSettings = new Global_Settings__c(Name = 'Default', Disable_Triggers__c = true); if(globalSettings != null) insert globalSettings; ...


1

That object is a platform event. You can view that in Setup > Platform Events. The trigger is written on insert and it is likely not getting covered because of the commented line in the test class //EventBus.publish(dc); which will invoke this trigger. You should uncomment this line an run the test. Make sure to pupulate details like ...


0

In VS Code, go to the terminal window and enter this command: sfdx force:apex:log:tail --color | grep USER_DEBUG Then run your tests. The debug messages will show up in the Terminal window.


3

This isn't something you can do in Ant directly. You would need to build a temp folder, copy the files you need to this folder, and deploy that instead. This was a limitation of the older metadata api (mdapi for short). Use Salesforce DX if you want this type of flexibility: sfdx force:source:deploy -p force-app/main/default/classes/AccountController.cls -l ...


2

The classes in classes folder and in package.xml should be an exact match. Else deployment will fail. The deployment parameters like which test classes to run can be specified in ant build file like. <target name="deployCode"> <sf:deploy username="${sf.username}" password="${sf.password}" sessionId="${sf.sessionId}" serverurl="${sf....


0

In the ANT deployment folder.. keep only those classes which u want to deploy and in buid.xml file add those test classes which u want to run. like below i have <target name="deployCodeCheckOnly"> <sf:deploy username="${sf.username}" password="${sf.password}" sessionId="${sf.sessionId}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" ...


2

Never mind i got it working as "import { createElement } from 'c/meetingRooms';" it should be "import { createElement } from 'lwc';"


1

Do you read this module: https://trailhead.salesforce.com/en/content/learn/modules/apex_integration_services/apex_integration_rest_callouts It's a perfect start of research related with the topic of Integration Services and bring excellent recommendation and best practice.


1

From my perspective a unit test tests an Apex class/method in isolation. The flow is external to the Apex and isn't something to be tested together with the Apex code in a unit test. Sure, you might want to do that in an integration test, but this isn't needed to increase code coverage. There are various ways to deal with this sort of scenario. My ...


Top 50 recent answers are included