What is "The Cloud"?
In the case of Salesforce.com (SFDC), it is a remote (off site) collection of hardware that is shared by multiple tenants, and maintained by another party.
Let that sink in a moment...
I can buy the rights to a server farm for a lot less than it would cost me to maintain one myself. No hardware to maintain, no people to carry out the maintenance, no real estate to hold it in. The entire infrastructure is leased out to me the tenant. This is IaaS, or Infrastructure as a Service. This allows the small 10 person company to have access to the same high performance machines and service that big businesses like Qualcomm, Dell, Siemans and Starbucks use. This is pretty darn cool. It puts some pretty powerful tools in the hands of a lot of people who may not have had the finances to access them on their own. But that is just the hardware. What about the software?
SFDC also provides robust CRM software. SaaS, or Software as a Service, is the other side of the Cloud coin for SFDC. Hosted on their infrastructure, SFDC software offers an out of the box solution to simple CRM processes. But with the use of their proprietary APEX and Visualforce languages, custom solutions can be built to allow for any business rules, workflow, and process to be brought into the package. And again all of these tools are available to anyone with a license, and free to developers who want to hone their skills.
So, here we all are playing happily in the same sandbox. But what happens when someone has an accident? What if I write a piece of code that shuts down a server with an endless loop, or build so many data calls into my code that i take too many system resources?
SFDC manages these risks through the use of Governor Limits and Test Classes.
Test Classes are a collection of method calls designed to run through your code looking for potential Governor Limit violations and logic errors. I will delve deeper into how I write test classes in a later post. For now lets just consider the fundamentals. Here are some considerations:
- Your entire Production Environment must have a minimum average coverage of 75%
- This is over total lines of code across all classes.
- While testing to 75% is the minimum, 100% should always be the goal.
- You can not deploy a controller or object that breaks another one already deployed.
- When you deploy a file you will be required to validate the entire Production package.
- If you make a change in Production that causes a controller to fail its test, you will be required to fix it before deploying any other files apart from the updated file.
- If your coverage is too low, deploying a hot fix may not be possible.
- Controllers, and Triggers require Test Classes
- Visualforce pages do not require Test Classes
- It is best practice to develop the Test Class and Controller in a sandbox environment and deploy them together.
- Properly identified Test Classes do not count towards your total code limit.
Test classes call each line of your code in a controlled environment to help you:
- Identify logic loops that never end.
- Find queries that return too many results
- Find queries that reference objects that do not exist
- Find SOQL (Salesforce Object Query Language, and more on that in another entry!) statements that reach Governor Limits
This is just the tip of the iceberg on Test Classes. I will go into more and more detail in future blog posts, but for now just consider that even though it seems like you are writing a lot of extra code, having these Test Classes required really puts you the Developer in a position to learn how you should be developing. It is much easier to test a class that uses only the queries and SOQL it needs to. Write clean and efficient code and Test Classes will be a fairly routine exercise.
No comments:
Post a Comment