unit testing in force.com platform

15
Unit Testing in Apex Chamil Madusanka

Upload: chamil-madusanka

Post on 11-May-2015

337 views

Category:

Technology


1 download

DESCRIPTION

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

TRANSCRIPT

Page 1: Unit testing in Force.com platform

Unit Testing in Apex

Chamil Madusanka

Page 2: Unit testing in Force.com platform

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 test-driven development process

• Test development that occurs at the same time as code development.

Page 3: Unit testing in Force.com platform

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

Page 4: Unit testing in Force.com platform

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

Page 5: Unit testing in Force.com platform

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

Page 6: Unit testing in Force.com platform

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

Page 7: Unit testing in Force.com platform

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

Page 8: Unit testing in Force.com platform

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

Page 9: Unit testing in Force.com platform

Structure of Test class

@isTest

private classTest_class

{

public static testMethod void test_name()

{

//code_block;

}

}

Page 10: Unit testing in Force.com platform

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

}

}

Page 11: Unit testing in Force.com platform

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

Page 12: Unit testing in Force.com platform

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

}

}

Page 13: Unit testing in Force.com platform

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.

Page 14: Unit testing in Force.com platform

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,Integermonth,Integer date)

– Use a date in the past