Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

I am new to apex and salesforce developing. I have written an apex trigger and a test class. The trigger compiles and I tested in my sandbox to make sure it does what I want. My test class runs successfully and my code is allegedly 100% covered. I am still a little nervous to deploy these changes to production (although they are validated).

Is there any good rule of thumb to know if my code really does what it says it does? If I deploy something and then delete it will the system return to exactly to the way it was before I deployed the trigger or will this require something more drastic?

Any input on this would be very much appreciated. I don't want to break anything!

Thanks very much! -Maureen

In case it is useful, I am pasting in the trigger I am using here. The trigger populates a custom field on a child object of Opportunity with the Opportunity RecordTypeID.

trigger PopoulatePin on Child__c (before insert){

    Set<id>parentIds = new Set<id>();
    for (Child__c r :trigger.new){
        parentIds.add(r.Child_Lookup__c);}

    Map<id,Opportunity> parentsByID = new Map<id,Opportunity>();
    parentsByID.putAll([SELECT id,RecordTypeId from Opportunity where id IN :parentIds]);

    for(Child__c r : trigger.new){
            r.PIN__c = parentsByID.get(r.Child_Lookup__c).RecordTypeId;            
    }
}
share|improve this question

2 Answers 2

From a cursory inspection, it looks like your code will work, but there are a few things I'd point out:

  • formula fields, workflow field updates, and SOQL queries are all capable of reflecting the RT ID from a parent object to its children. I'd suggest looking into these instead of a trigger for what you're trying to do.
  • what are you trying to actually accomplish? I don't see many use cases for copying the RT ID of a parent to its child that can't be addressed by formulas, queries, or by some other approach.
  • this trigger won't fire if a child object's parent has its RecordType changed (if your configuration allows that).
  • this trigger won't fire if a child object is re-homed (if your configuration allows that).
  • I would assume child has a Master-Detail relationship with Opp, but if it doesn't, and users may enter child records without "parent" opportunities in the lookup field, you will get null pointer exceptions in those cases.
share|improve this answer

Sounds like you're off to a good start. Your test methods should test that your code actually does what it should do...

Essentially your test methods should run through three main phases

  1. Setup test data
  2. Run the appropriate code
  3. Use System.Assert() statements to verify that the changes the code should have made worked as expected.

e.g. in your scenario you'd insert an opportunity record with a specific record type ID for step 1. Then you'd insert a Child__c record for step 2, where Child_Lookup__c points to that opportunity. Then for step 3 you'd use something like:

System.Assert(child.PIN__c == oppty.RecordTypeId, 'Expected PIN__c to be ' + oppty.RecordTypeId + ' but got ' + child.PIN__c);

This call will fail if the field hasn't been updated correctly, and the "Expected..." message will appear in logs to make it easier to debug.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.