Unit testing in Force.com platform
Upcoming SlideShare
Loading in...5

Unit testing in Force.com platform



This presentation is based on the unit testing of Force.com platform. It includes best practices, considerations of Salesforce unit testing

This presentation is based on the unit testing of Force.com platform. It includes best practices, considerations of Salesforce unit testing



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Unit testing in Force.com platform Unit testing in Force.com platform Presentation Transcript

  • Unit Testing in Apex Chamil Madusanka
  • Understanding Testing in Apex • Testing is the key to successful long term development • critical component of the development process. • salesforce.com strongly recommends to use a testdriven development process • Test development that occurs at the same time as code development.
  • Before deploy or upload the code or package……….. • • • • 75% of your Apex code must be covered by unit tests All the tests must complete successfully Every trigger has some test coverage (1%) All classes and triggers must compile successfully View slide
  • What to test? • Single Action – Test to verify that a single record produces the correct, expected result. • Bulk Action – test not only the single record case, but the bulk cases as well • Positive Behavior – verify that the expected behavior occurs through every expected permutation • Negative Behavior – Verify that the error messages are correctly produced • Restricted User – Test whether a user with restricted access to the sObjects used in your code sees the expected behavior View slide
  • Test Class • Test classes defined by @isTest annotation • Before Winter ’12 Release – Test classes have to be private • On Winter ‘12 Release – Test Classes can be public or private
  • Test Class cont……. • Public Test Classes – Expose common methods for test data creation – Setting up data that the tests need to run against. – Methods of a public test class can only be called from a running test – Cannot be called by a non-test request
  • Test Class cont……. • When you create a test method, – Use static – Use testMethod keyword – Use void return type – No any arguments – No data changes performed in a test method – Don’t send emails – Cannot be used to test Web service callout • The API for asynchronous test runs is a Beta release (Winter ‘12) • For More : Force.com Apex code Developer’s Guide Page 153
  • Test Class cont……. • The key methods to use in your unit tests are the system.assert() methods – System.assert(condition) – System.assertEquals(x,y) – System.assertNotEquals(x,y) • For the security review, every test method must have at least one system.assert() method
  • Structure of Test class @isTest private classTest_class { public static testMethod void test_name() { //code_block; } }
  • Structure of public Test class for test data creation @isTest public class TestUtil { public static void createTestAccounts() { // Create some test accounts } public static void createTestContacts() { // Create some test contacts } }
  • New IsTest(OnInstall=true) Annotation • Control the Apex test classes during the package installation • Can be used for managed or unmanaged packages • No longer possible to bypass a failing test during package installation • A test method or a class won't be executed during installation – Doesn't have this annotation – Annotated with isTest(OnInstall=false) – Annotated with isTest • This annotation applies only to packages uploaded in Winter ’12 or later
  • IsTest(OnInstall=true) Annotation cont… public class OnInstallClass { public void method1() { // Some code } // This test method will be executed during the installation of the // package. @isTest(OnInstall=true) static void test1() { // Some test code } // Tests excluded from running during the installation of a package. @isTest static void test2() { // Some test code } static testmethod void test3() { // Some test code } }
  • Best Practice for Writing Test Classes • Write fully portable tests – – – – You write tests in the context of a Developer or Sandbox org. You can write tests that rely on specific pieces of data If you do that, your tests will fail on deployment Use relative URLs and query for names of data records rather than their specific Ids. • Don’t use production data in your tests • Test expected behavior first, then unexpected behavior – Start with testing simple cases, and test to make sure that what you expect to happen is indeed happening. – Then make sure to add test cases for behavior you don’t expect, but could happen. – This is why they tell developers never to write their own tests, because we all believe our code will behave as expected.
  • Best Practice for Writing Test Classes cont….. • If you find a bug, write a test to expose it before you fix it • Shoot for 100% coverage – Try to test everything – It’s not always fun or even possible, but try • Don’t rely on Today() – If you are using dates in your code, don’t build your dates on Today() – Use Date.newInstance(Integer year,Integer month,Integer date) – Use a date in the past
  • Reference • http://www.salesforce.com/us/developer/docs/a pexcode/salesforce_apex_language_reference.pd f • http://gokubi.com/archives/testing-bestpractices • http://www.salesforce.com/us/developer/docs/a pexcode/Content/apex_testing_example.htm • http://www.salesforce.com/us/developer/docs/p ages/Content/pages_controller_error_handling.h tm