Salesforce.com constantly pushes practice for Test Driven Development. My feel of using TDD is that it is a great habit because of some reasons.
I will refer to this site for TDD http://www.agiledata.org/essays/tdd.htmlhttp://www.agiledata.org/essays/tdd.html
What developer benefits is that he/she tries to write smaller classes and methods. When classes and methods are smaller and only try to do a specific job, then it is easier to write the test cases.
What we get at end? A lot more code to reuse because many small classes actually lands as helper class and removes problem of tightly coupled code.
‘Where to put tests? Unit tests should be placed in a separate class file in Salesforce. It is also important to have tests in a separate class because if your org becomes too large and you want Salesforce to expand the code limit in your org, then Salesforce will ask you to make sure that all tests are in their own classes before the code limit will be expanded.
How to write tests for some standard objects record insertion? This is very common and we need to use in multiple cases. Every time we need to find out old tests or write new one. It is handy practice to have a note of reusable chunk of code like below for repeated use:
I will refer to this site for TDD http://www.agiledata.org/essays/tdd.htmlhttp://www.agiledata.org/essays/tdd.html
What developer benefits is that he/she tries to write smaller classes and methods. When classes and methods are smaller and only try to do a specific job, then it is easier to write the test cases.
What we get at end? A lot more code to reuse because many small classes actually lands as helper class and removes problem of tightly coupled code.
‘Where to put tests? Unit tests should be placed in a separate class file in Salesforce. It is also important to have tests in a separate class because if your org becomes too large and you want Salesforce to expand the code limit in your org, then Salesforce will ask you to make sure that all tests are in their own classes before the code limit will be expanded.
How to write tests for some standard objects record insertion? This is very common and we need to use in multiple cases. Every time we need to find out old tests or write new one. It is handy practice to have a note of reusable chunk of code like below for repeated use:
@IsTest(SeeAllData=true)
public with sharing class TriggerTestClass {
static testMethod void validateTrigger() {
Account acc= new Account(Name = 'testAcc',BillingStreet='testStreet',BillingCity ='tectcity',BillingState='testState',BillingPostalCode='123',
BillingCountry='testcountry',Description='testdesc');
insert acc;
//Case record in Test method.
Contact conObj = new Contact();
conObj.lastname = 'testcon';
conObj.AccountId = acc.id;
insert conObj;
Case caseObj = new Case();
caseObj.ContactId = conObj.Id;
caseObj.AccountId = acc.Id;
caseObj.Status = 'New Entry';
caseObj.ContactId = conObj.Id;
caseObj.Origin = 'Email';
insert caseObj;
Opportunity opp= new Opportunity(AccountId=acc.id,Amount=1234.00,Description='testdesc',Name='testOpp',
StageName='Prospecting',CloseDate = System.Today());
insert opp;
PricebookEntry priceBookEntryNew = new PricebookEntry();
Product2 product = new Product2();
PriceBook2 pb2 = new PriceBook2 (Name='Standard priceBook',Description = 'test');
insert pb2;
List pricebookList = [Select id from PriceBook2 where IsStandard = TRUE ];
PriceBook2 pricebooktest = new PriceBook2 ();
if(pricebookList != null && pricebookList.size()>0)
pricebooktest = pricebookList.get(0);
product.name = 'Test';
insert product;
priceBookEntryNew.Product2Id = product.Id;
priceBookEntryNew.PriceBook2Id = pricebooktest.Id;
priceBookEntryNew.UnitPrice = 20.00;
priceBookEntryNew.UseStandardPrice = false;
priceBookEntryNew.isactive = true;
insert priceBookEntryNew;
OpportunityLineItem oli = new OpportunityLineItem
(
OpportunityId = opp.Id,
PricebookEntryId = priceBookEntryNew.Id,
Quantity = 1,
UnitPrice = priceBookEntryNew.UnitPrice,
ServiceDate = System.today()
);
insert oli;
}
}