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
Janice SwinehartJanice Swinehart 

Testing and deploying to production

I am not an Apex developer.  I fumbled my way through creating a trigger in the sanbox to update data on the OpportunityLineItem.  I now need in production and have discovered I need it to go through testing?  Can someone help by providing steps to get this quickly tested and deployed to production?

trigger SetSyndicatedRevenueSchedule on OpportunityLineItem (before insert) {
    List<OpportunityLineItemSchedule> itemschedule = new List<OpportunityLineItemSchedule>();
    for (OpportunityLineItem o: Trigger.new)
    {
      if (o.Product_Subscription__c == False)
      {
        // o.Description = 'Hello World';
        o.ServiceDate = o.Report_Selling_Date__c;
        
        itemschedule.clear();
        // itemschedule = [Select id, ScheduleDate from OpportunityLineItemSchedule where OpportunityLineItemId =: o.Id Order by ScheduleDate ASC];
        itemschedule = [Select ScheduleDate from OpportunityLineItemSchedule where OpportunityLineItemId =: o.Id Order by ScheduleDate ASC];
        System.Debug('Test: ' + itemschedule);
        
        for (OpportunityLineItemSchedule rs: itemschedule)
        {
            rs.ScheduleDate = o.ServiceDate;
            update itemschedule;
        }
      }
    }
}

 
Ryan GreeneRyan Greene
Hello,
With your trigger you should not need to write a test.
To deploy go to Setup from your Sandbox type "Outbound Change Sets" in quick find, click New, name it, click Save. Then in your Change Set click Add under Change Set Components and select Apex Trigger from type, select your trigger and click Add To Change Set. When you're ready click Upload on your Change Set. Then select your Production Org and click Upload.

Then go to your Production, go to Setup and type "Inbound Change Sets" in quick find. Your outbound change set should show in the inbound, keep in mind it can take up to an hour for it to be ready for deployment, and may even take 10 to 20 mintues before it shows in Inbound. Once it's ready, click Deploy, Run Standard Tests, and it should be good unless there are errors in the code which it will tell you.
Janice SwinehartJanice Swinehart
Hi Ryan, Thanks for the reply. When I deploy in production, there is no option for Run Standard Tests. There is Default, Run local test, Run all tests and Run specified tests. When I did it originally with Default, the deployment failed saying the triggers have 0% code coverage.
Ryan GreeneRyan Greene
Sorry, I forget which option it is, must be Run All or Run Local. I have several triggers which I deployed with no tests written, usually the tests already built in will cover a portion of the trigger.
David M. ReedDavid M. Reed
The code coverage rules require that all triggers have at least some coverage, a requirement that is over and above the standard 75% overall code coverate requirement. Ryan is correct that sometimes test code for other classes might "accidentally" cover the trigger, but it's not a good idea to rely on this. Best practice is to write unit tests that cover all code you deploy so that you know it does what you expect.

This trigger also has some issues with bulkification. Specifically, you have a SOQL query in a `for` loop, and a DML operation in a nested `for` loop. This is very likely to result in hitting platform governor limits, resulting in errors. Trailhead has a good module on trigger bulkification that might help: https://trailhead.salesforce.com/en/modules/apex_triggers/units/apex_triggers_bulk

If you're not comfortable with writing code, this functionality could also be accomplished using the combination of Process Builder and Flow. You are not required to write tests for processes and flows.