6

I am trying to write test cases for an Apex trigger that I have in the sandbox.

My assumption is that I write the test case in the same place I wrote the trigger, just after it.

so I have

trigger AssignCommissionOwnerAccount on Account (before update) {
    for(Account sAcct : trigger.new){
        sAcct.Commission_Owner_Account__c = sAcct.OwnerId;       
    }
}
@isTest
private class doATest {
    static testmethod doSomething() {
        System.assertEquals(1,1);
    }
}

I had more sophisticated test code, but I lost it, because I got this error

Error: Compile Error: unexpected token: @ at line 6 column 0    

Which seems to indicate that I was putting my test in the wrong place. How can I write test cases for my Apex Triggers?

10

You need to create a separate Apex Class for the trigger test. Your code is fine, you just need to create a new separate class for the test code. I generally try to keep a naming convention for my test classes.

*Note - There are many different naming conventions out there, this is just the one that I prefer

So if my trigger class was

MyApexAccountTrigger

Then my test class would be

MyApexAccountTrigger_test

This way the test class is always listed directly next to the the class it tests and you don't have to go searching for it

trigger AssignCommissionOwnerAccount on Account (before update) {
    for(Account sAcct : trigger.new){
        sAcct.Commission_Owner_Account__c = sAcct.OwnerId;       
    }
}

This is your seperate test class

@isTest
private class AssignCommissionOwnerAccount_test {
    static testmethod doSomething() {
        System.assertEquals(1,1);
    }
}
  • 2
    Depending on the complexity, you might also just have a single class that holds all the test cases for all triggers. Consolidated classes helps with the clutter, but large classes are problematic to edit in the UI. The key is consistency. Either group them all into one place, or come up with a common naming scheme, as suggested here. Also, to make your life easier, don't use a naming scheme such as Test_MyClass, because that makes finding the tests challenging. Instead, MyClass_Test makes life easier. – sfdcfox Dec 4 '13 at 22:55
  • This Introduction to Apex Code Test Methods may be useful wiki.developerforce.com/page/… – BarCotter Dec 4 '13 at 23:28
  • One other thing, I also use a convention, but I put Test_ at the start, keeps them all grouped together when sorted alphamabetically. – Matt Lacey Dec 5 '13 at 4:45
  • I have used both prepending classes with test_ and appending test at the end. I see value in both. You are right that by prepending it, you have all your test classes together. I have found I prefer to append it to the end as it will always appear just after the class in which it tests. Really just a personal preference. If you want to have the tests next to the class in which they test, add _test at the end. If you prefer to have all your test classes grouped together, then add test at the beginning. Just whatever floats your boat. Definitely see value in both. – Chris Duncombe Dec 5 '13 at 11:33
  • 1
    The general point is consistency. For example, in the project I work on at work, all trigger tests are in a single class, so any new ones we add would go there, too. All controllers and extensions have the form: <Object><Controller|Extension><Test?>, e.g. AssetController, AssetExtension, AssetExtensionTest. Naming conventions are an important part of any project, but especially so for salesforce.com. FYI, putting "test" at the end lets you see the tests after their respective class, and you can still make list views for "name contains test" to see just test methods in the UI. – sfdcfox Dec 5 '13 at 17:32
6

Tests should always put in their own class marked @IsTest. There are a number of reasons for this:

  1. Anything marked at the class level @IsTest isn't counted against your total lines of code allowed in the org. This may not seem like a problem, but some orgs have a ton of code.
  2. It helps improve code performance. Salesforce caches the byte code for classes and if they have tests in them too, then it slows things down a tiny bit.
  3. It is required when writing code with API version of 28 or higher.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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