I will be launching my long awaited App on the AppExchange in about 8 weeks. Wow how time flies, it's been 2 years + since I started developing my App, Self Evolving Software or SES.
SES is simply the holy grail of software development, the ability for a computer program to understand what is required in English and hunt down functions in the codebase to fulfill a particular requirement.
Development teams commonly duplicate code because they are not aware that the same function has already been developed by another developer, this may be in the same organization or not. Every time this happens an organization loses money in costly developers time and also by unnecessarily delaying IT projects.
SES literally automates the processes of finding relevant functions from the codebase and creating the code using these functions to fulfill the business requirement.
By utilizing crowd sourcing software development in SES is a catalyst to faster, more accurate and efficient software development.
Saturday, 1 September 2012
Tuesday, 12 June 2012
Multiple Users on Tasks
Multiple Users on Tasks
Assigning a Task to Multiple Users sounded great. I was looking forward to 1 user out of a Group closing a Task, so whoever got there first would be able to close the Task.
Not quite. The new amazing piece of technology by Salesforce simply creates a Task for every user in the Public Group or Role.
Fantastic, not quite
Sunday, 10 June 2012
Salesforce to Salesforce Attachments Documents and Tasks
Ive blogged about Salesforce to Salesforce before and how to programmatically pass records from 1 org to another, but I wanted to blog about specifically how to pass over certain records, such as Attachments and Tasks etc
list<PartnerNetworkRecordConnection> newrecords = new list<PartnerNetworkRecordConnection>();
List<PartnerNetworkConnection> connMap = new List<PartnerNetworkConnection>();
connMap=[select Id, ConnectionStatus, ConnectionName from PartnerNetworkConnection where ConnectionStatus = 'Accepted' and ConnectionName=<<connection>> LIMIT 1] ;
Account[] acc =[Select id From Account where Name = <<account>> limit 1];
Attachment[] attaches =[Select id,IsPartnerShared,Name From Attachment where Parentid=: acc[0].id and IsPartnerShared=false limit 1];
if (attaches.size() > 0){
Set<id> newfunctions = new Set<id>();
for(Attachment thisattach: attaches) {
PartnerNetworkRecordConnection newrecord = SearchFunctionUtils.addPartnerNetworkRecordConnection(connMap);
if (!Test.isRunningTest()){
newrecord.LocalRecordId = acc[0].id ;
newrecord.RelatedRecords = 'Attachment';
newrecords.add(newrecord);
}
newfunctions.add(thisattach.id);//Attachments to be uploaded
}
insert newrecords;
}
The key difference is you have to set RelatedRecords and the LocalRecordId is not the id of the Attachment but Id of the Account. There are also other standard objects which also require to use this method, which I have found are poorly documented. The best way of identifying which objects is probably by trial and error, but the Document object is another such object.
For Tasks SendClosedTasks and SendOpenTasks properties are important.
Seefor more details
http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_partnernetworkrecordconnection.htm
list<PartnerNetworkRecordConnection> newrecords = new list<PartnerNetworkRecordConnection>();
List<PartnerNetworkConnection> connMap = new List<PartnerNetworkConnection>();
connMap=[select Id, ConnectionStatus, ConnectionName from PartnerNetworkConnection where ConnectionStatus = 'Accepted' and ConnectionName=<<connection>> LIMIT 1] ;
Account[] acc =[Select id From Account where Name = <<account>> limit 1];
Attachment[] attaches =[Select id,IsPartnerShared,Name From Attachment where Parentid=: acc[0].id and IsPartnerShared=false limit 1];
if (attaches.size() > 0){
Set<id> newfunctions = new Set<id>();
for(Attachment thisattach: attaches) {
PartnerNetworkRecordConnection newrecord = SearchFunctionUtils.addPartnerNetworkRecordConnection(connMap);
if (!Test.isRunningTest()){
newrecord.LocalRecordId = acc[0].id ;
newrecord.RelatedRecords = 'Attachment';
newrecords.add(newrecord);
}
newfunctions.add(thisattach.id);//Attachments to be uploaded
}
insert newrecords;
}
The key difference is you have to set RelatedRecords and the LocalRecordId is not the id of the Attachment but Id of the Account. There are also other standard objects which also require to use this method, which I have found are poorly documented. The best way of identifying which objects is probably by trial and error, but the Document object is another such object.
For Tasks SendClosedTasks and SendOpenTasks properties are important.
Seefor more details
http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_partnernetworkrecordconnection.htm
Saturday, 2 June 2012
How to extract as much performance improvement as possible from unit tests
I urge everyone to start adopting the following unit testing methodology because it will save a huge amount of time in your deployments and ensure quality coding simultaneously.
Some people like Paul Battisson have done a lot of work on using Mock objects to avoid doing DMLs to create test data for your unit tests, but isn't exclusively to help in this area,but this is what I want to concentrate on.
However Pauls work at the moment doesn't help the situation where you want to test your Triggers. Testing Triggers properly should involve bulk testing of 200 record DMLs. The only problem in doing this is every time you deploy every unit test of every Trigger will run 200 record DMLs, this is of course very expensive and will slow down your deployments.
So what we need is a combinationof using Mock objects to test the bulk of your code, but to test your Triggers on first deploy we should test a full 200 record DMLs, and on subsequent deploys to just test a handful of records, say 10 records, which is less expensive and so will speed up your deployments. But with the built in ability to increase the number of DMLs whenever you need to.
It is likely that your trigger tests cumulatively account for 90% + of the DMLs that go on in all your test classes. So adddress this issue and you address the issue around deployment times being so long.
First of all look at Pauls work on Mock objects
https://github.com/pbattisson/Advanced-Force.com-Testing
Testing Triggers by Luke Emberton and Steven Fouracre
When deploying a trigger for the first time set a custom setting to 200,
so that up to 200 records are created in your unit test, after
deployment lower this to 10, so that future deployments are not slowed
down but the unit tests are still tested. If you are currently in an
empty sandbox, then the unit test needs to be written to populate the custom setting
with a default value of say10 to test 10 DMLs.
First step is to setup our Triggers correctly. Have a look at this article about the Trigger Pattern
http://www.embracingthecloud.com/2010/07/08/ASimpleTriggerTemplateForSalesforce.aspx
By testing the trigger I will indirectly test the class, so
you could just test the trigger, but that is not unit testing, because
what happens if the class is called from other classes and the trigger and unit test to the trigger is
removed, there is now potentially nothing covering the class. Also I like to make it obvious where the
unit test is that tests the trigger and class.
So testing the trigger, you need to test bulk DMLs, for the class just test for 1 record. To setup the test data I use the same function to test both trigger and class, or for you classes you could use Pauls Mock objects.
The following example is to test update and deletion triggers, but can be slightly modified for inserts as well, by ensuring whatever value is entered in the CS the number of new records is created.
public static void setupData(integer createData){
cLines = <<do soql>>; //find out how many records exist in this org
if (createData > cLines.size()){//there isnt enough records in this org, so you need to create more records
for (integer i=1; i<=(createData - cLines.size()); i++){
……..blah blah……create any extra records required
}
}
else{
//there are enough records in this org you don't need to create any more
}
}
createData tells the function how many records to setup. The code in the If statement only
creates however number of extra records are required to be created to test the trigger or class.
Of course this means you need to use @istest(SeeAllData=True)
The actual testmethod will likely be very similar for both tests for the trigger and class, except the number you are passing to setupData()
When testing the class the integer createData is set to 1, when testing the Trigger it is taken from a custom setting ( CS ) in the org. So when you are deploying your project, the CS is set to 200 to fully test your trigger, then it is lowered to say 10, so the Trigger is still tested for bulk operations, but future deployments are not slowed down by trying to create 200 DMLs. Of course the CS can be changed whenever you like for future upgrades to your trigger.
Create a CS called Test_Triggers__c , with field Records__c.
In your trigger test
Test_Triggers__c testTrigs = Test_Triggers__c.getinstance(<<object name>>);
integer recordCreate = (Integer)((testTrigs != null) ? testTrigs.Records__c : 10);
Now pass recordCreate to setupData()
If your CS is empty it will just set it to 10, otherwise it will pass the number of records to create to setupData(), and this function will soql the number of existing records in the org and work out how many more is needed to create. So after deployment lower your CS from 200 to 10 to continue testing your triggers for bulk operations.
Efficient, easily manageable and quality testing by Luke Emberton and Steven Fouracre
Enjoy!
Some people like Paul Battisson have done a lot of work on using Mock objects to avoid doing DMLs to create test data for your unit tests, but isn't exclusively to help in this area,but this is what I want to concentrate on.
However Pauls work at the moment doesn't help the situation where you want to test your Triggers. Testing Triggers properly should involve bulk testing of 200 record DMLs. The only problem in doing this is every time you deploy every unit test of every Trigger will run 200 record DMLs, this is of course very expensive and will slow down your deployments.
So what we need is a combinationof using Mock objects to test the bulk of your code, but to test your Triggers on first deploy we should test a full 200 record DMLs, and on subsequent deploys to just test a handful of records, say 10 records, which is less expensive and so will speed up your deployments. But with the built in ability to increase the number of DMLs whenever you need to.
It is likely that your trigger tests cumulatively account for 90% + of the DMLs that go on in all your test classes. So adddress this issue and you address the issue around deployment times being so long.
First of all look at Pauls work on Mock objects
https://github.com/pbattisson/Advanced-Force.com-Testing
Testing Triggers by Luke Emberton and Steven Fouracre
When deploying a trigger for the first time set a custom setting to 200,
so that up to 200 records are created in your unit test, after
deployment lower this to 10, so that future deployments are not slowed
down but the unit tests are still tested. If you are currently in an
empty sandbox, then the unit test needs to be written to populate the custom setting
with a default value of say10 to test 10 DMLs.
First step is to setup our Triggers correctly. Have a look at this article about the Trigger Pattern
http://www.embracingthecloud.com/2010/07/08/ASimpleTriggerTemplateForSalesforce.aspx
By testing the trigger I will indirectly test the class, so
you could just test the trigger, but that is not unit testing, because
what happens if the class is called from other classes and the trigger and unit test to the trigger is
removed, there is now potentially nothing covering the class. Also I like to make it obvious where the
unit test is that tests the trigger and class.
So testing the trigger, you need to test bulk DMLs, for the class just test for 1 record. To setup the test data I use the same function to test both trigger and class, or for you classes you could use Pauls Mock objects.
The following example is to test update and deletion triggers, but can be slightly modified for inserts as well, by ensuring whatever value is entered in the CS the number of new records is created.
public static void setupData(integer createData){
cLines = <<do soql>>; //find out how many records exist in this org
if (createData > cLines.size()){//there isnt enough records in this org, so you need to create more records
for (integer i=1; i<=(createData - cLines.size()); i++){
……..blah blah……create any extra records required
}
}
else{
//there are enough records in this org you don't need to create any more
}
}
createData tells the function how many records to setup. The code in the If statement only
creates however number of extra records are required to be created to test the trigger or class.
Of course this means you need to use @istest(SeeAllData=True)
The actual testmethod will likely be very similar for both tests for the trigger and class, except the number you are passing to setupData()
When testing the class the integer createData is set to 1, when testing the Trigger it is taken from a custom setting ( CS ) in the org. So when you are deploying your project, the CS is set to 200 to fully test your trigger, then it is lowered to say 10, so the Trigger is still tested for bulk operations, but future deployments are not slowed down by trying to create 200 DMLs. Of course the CS can be changed whenever you like for future upgrades to your trigger.
Create a CS called Test_Triggers__c , with field Records__c.
In your trigger test
Test_Triggers__c testTrigs = Test_Triggers__c.getinstance(<<object name>>);
integer recordCreate = (Integer)((testTrigs != null) ? testTrigs.Records__c : 10);
Now pass recordCreate to setupData()
If your CS is empty it will just set it to 10, otherwise it will pass the number of records to create to setupData(), and this function will soql the number of existing records in the org and work out how many more is needed to create. So after deployment lower your CS from 200 to 10 to continue testing your triggers for bulk operations.
Efficient, easily manageable and quality testing by Luke Emberton and Steven Fouracre
Enjoy!
Monday, 7 May 2012
SeeAllData annotation in Spring 12 Salesforce Release
SeeAllData annotation opens up a number of interesting things to think about.
Of course when unit testing a good developer will create his/her own test data to ensure that your unit tests will equally work in environments (live and sandbox) where there is not enough sufficient data to test.
So with API 24 SeeAllData is set to False as standard, where test methods don’t have access by default to pre-existing data in the organization.
So that's good, right?
Well yes and no. It is also important to test under conditions where there is a lot of data to ensure that your tests equally work. Have you ever come across situations where your unit tests work in your developer sandbox, you deploy to the Full UAT Sandbox and you find that your unit tests no longer work.
This can happen because of many reasons, soqls designed with no limits, limits on soqls are too restrictive and don't pick up the intended data, triggers work on a small number of records, but break on bulk uploads of say 200 records and so on.
So if you only test where SeeAllData is set to False this won't fully test your classes.
So I suggest you create 2sets of unit test methods 1 where SeeAllData is False, 1 for True. Test methods will be exactly the same, but creation of test data is different.
The isTest(SeeAllData=true) annotation is used to open up data access when applied at the class or method
level. However, using isTest(SeeAllData=false) on a method doesn’t restrict organization data access for that
method if the containing class has already been defined with the isTest(SeeAllData=true) annotation. In this
case, the method will still have access to all the data in the organization.
Say you are testing an insert trigger on the Account.
Set your class to be SeeAllData=false, which is default
Set TestMethod SeeAllData is False is quite straight forward
Test your classes under an data empty environment, so you need to create
Account thisAccount = new Account(Name='Steves test account');
insert thisAccount;
Set TestMethod SeeAllData is True
Test your class under full data conditions to ensure your classes still work.
First identify how many Accounts currently exist in the system, there's no point in making the system create more Accounts than it needs to.
Account[] thisAccountTest = [select Id from Account limit 200];
Account[] newAccs = new Account[]{};
if (thisAccountTest.size() < 200){
for (integer i=0; i<=200 - thisAccountTest.size() ; i++){
newAccs.add(new Account(Name='Steves test account' + i));
}
insert newAccs;
}
You may ask why not just create tests where SeeAllData is True and create all the Accounts you need to.
Well it's slower to run this test so when you are deploying new code to the live environment this will slow down each deployment. The answer is to force your unit tests to run your test methods that are annotated SeeAllData is True only during deployment to the live environment and other deployments will only run SeeAllData is False test methods.
At the moment it's quite difficult to stop SeeAllData is True tests running only on deployment, so the best alternative approach at the moment is to first Validate all your code to Live environment with the SeeAllData is True test class included. So long as your validation passes, now deploy your code without the SeeAllData is True test methods.
I suspect that Salesforce will at some point allow you to run certain test classes only at deployment, but for now this is not possible.
Note:
Test code saved against Salesforce API version 23.0 or earlier continues to have access to
all data in the organization and its data access is unchanged. So if your environment contains a lot of data your tests will run much slower.
Of course when unit testing a good developer will create his/her own test data to ensure that your unit tests will equally work in environments (live and sandbox) where there is not enough sufficient data to test.
So with API 24 SeeAllData is set to False as standard, where test methods don’t have access by default to pre-existing data in the organization.
So that's good, right?
Well yes and no. It is also important to test under conditions where there is a lot of data to ensure that your tests equally work. Have you ever come across situations where your unit tests work in your developer sandbox, you deploy to the Full UAT Sandbox and you find that your unit tests no longer work.
This can happen because of many reasons, soqls designed with no limits, limits on soqls are too restrictive and don't pick up the intended data, triggers work on a small number of records, but break on bulk uploads of say 200 records and so on.
So if you only test where SeeAllData is set to False this won't fully test your classes.
So I suggest you create 2sets of unit test methods 1 where SeeAllData is False, 1 for True. Test methods will be exactly the same, but creation of test data is different.
The isTest(SeeAllData=true) annotation is used to open up data access when applied at the class or method
level. However, using isTest(SeeAllData=false) on a method doesn’t restrict organization data access for that
method if the containing class has already been defined with the isTest(SeeAllData=true) annotation. In this
case, the method will still have access to all the data in the organization.
Say you are testing an insert trigger on the Account.
Set your class to be SeeAllData=false, which is default
Set TestMethod SeeAllData is False is quite straight forward
Test your classes under an data empty environment, so you need to create
Account thisAccount = new Account(Name='Steves test account');
insert thisAccount;
Set TestMethod SeeAllData is True
Test your class under full data conditions to ensure your classes still work.
First identify how many Accounts currently exist in the system, there's no point in making the system create more Accounts than it needs to.
Account[] thisAccountTest = [select Id from Account limit 200];
Account[] newAccs = new Account[]{};
if (thisAccountTest.size() < 200){
for (integer i=0; i<=200 - thisAccountTest.size() ; i++){
newAccs.add(new Account(Name='Steves test account' + i));
}
insert newAccs;
}
You may ask why not just create tests where SeeAllData is True and create all the Accounts you need to.
Well it's slower to run this test so when you are deploying new code to the live environment this will slow down each deployment. The answer is to force your unit tests to run your test methods that are annotated SeeAllData is True only during deployment to the live environment and other deployments will only run SeeAllData is False test methods.
At the moment it's quite difficult to stop SeeAllData is True tests running only on deployment, so the best alternative approach at the moment is to first Validate all your code to Live environment with the SeeAllData is True test class included. So long as your validation passes, now deploy your code without the SeeAllData is True test methods.
I suspect that Salesforce will at some point allow you to run certain test classes only at deployment, but for now this is not possible.
Note:
Test code saved against Salesforce API version 23.0 or earlier continues to have access to
all data in the organization and its data access is unchanged. So if your environment contains a lot of data your tests will run much slower.
Thursday, 3 May 2012
Autonumbers Increment In Unit Tests
Autonumbers increment when running a testmethod in unit tests. So we you go back to the real world the next number produced by an auto number field is 1 more than previous.
Surely not you say.
Sorry, but true. So how do you change this. You have to turn off a setting in salesforce, so you will have to raise a Salesforce Case to set a flag to default=off on specified custom objects.
For more information review
http://success.salesforce.com/
Surely not you say.
Sorry, but true. So how do you change this. You have to turn off a setting in salesforce, so you will have to raise a Salesforce Case to set a flag to default=off on specified custom objects.
For more information review
http://success.salesforce.com/
Thursday, 9 February 2012
Dont be fooled by Currency data type
The Currency data type may display values as 2 decimal places, but the actual value stored in Salesforce database can have more decimal places.
If data is uploaded via data loader or similar tool values could be uploaded with more decimal places.
You may see the value in Salesforce with 2 decimal places, but if you perform a soql the value will have multiple decimal places.
If data is uploaded via data loader or similar tool values could be uploaded with more decimal places.
You may see the value in Salesforce with 2 decimal places, but if you perform a soql the value will have multiple decimal places.
Subscribe to:
Posts (Atom)