salesforce.com strongly recommends that you use a test-driven development process, that is, test development that occurs at the same time as code development.
Why Test Apex?
* Testing is key to the success of your application, particularly if your application is to be deployed to customers.
* If you validate that your application works as expected, that there are no unexpected behaviors, your customers are going to trust you more.
* There are two ways of testing an application.
1. One is through the Salesforce user interface, important, but merely testing through the user interface will not catch all of the use cases for your application.
2. The other way is to test for bulk functionality: up to 200 records can be passed through your code if it's invoked using the Force.com Web services API or by a Visualforce standard set controller.
* You will have additional releases of it, where you change and extend functionality.
* If you have written comprehensive tests, you can ensure that a regression is not introduced with any new functionality.
Before you can deploy your code or package it for the Force.com AppExchange, the following must be true:
• 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully.
Note the following:
- When deploying to a production organization, every unit test in your organization namespace is executed.
- Calls to System.debug are not counted as part of Apex code coverage in unit tests.
- While only 75% of your Apex code must be covered by tests, your focus shouldn't be on the percentage of code that is covered.
- Instead, you should make sure that every use case of your application is covered, including positive and negative cases, as well as bulk and single record.
- This should lead to 75% or more of your code being covered by unit tests.
• Every trigger has some test coverage.
• All classes and triggers compile successfully.
Note:
Salesforce runs all tests in all organizations with Apex scripts to verify that no behavior has been altered as a result of any service upgrades.
What to Test in Apex
Salesforce.com recommends that you write tests for the following:
Single action
Test to verify that a single record produces the correct, expected result.
Bulk actions
Every Apex script, whether a trigger, a class or an extension, may be invoked for 1 to 200 records. You must test not only the single record case, but the bulk cases as well.
Positive behavior
Test to verify that the expected behavior occurs through every expected permutation, that is, that the user filled out everything correctly and did not go past the limits.
Negative behavior
There are likely limits to your applications, such as not being able to add a future date, not being able to specify a negative amount, and so on.
You must test for the negative case and verify that the error messages are correctly produced as well
as for the positive, within the limits cases.
Restricted user
Test whether a user with restricted access to the sObjects used in your code sees the expected behavior.
Note: Conditional and ternary operators are not considered executed unless both the positive and negative branches are executed.
Why Test Apex?
* Testing is key to the success of your application, particularly if your application is to be deployed to customers.
* If you validate that your application works as expected, that there are no unexpected behaviors, your customers are going to trust you more.
* There are two ways of testing an application.
1. One is through the Salesforce user interface, important, but merely testing through the user interface will not catch all of the use cases for your application.
2. The other way is to test for bulk functionality: up to 200 records can be passed through your code if it's invoked using the Force.com Web services API or by a Visualforce standard set controller.
* You will have additional releases of it, where you change and extend functionality.
* If you have written comprehensive tests, you can ensure that a regression is not introduced with any new functionality.
Before you can deploy your code or package it for the Force.com AppExchange, the following must be true:
• 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully.
Note the following:
- When deploying to a production organization, every unit test in your organization namespace is executed.
- Calls to System.debug are not counted as part of Apex code coverage in unit tests.
- While only 75% of your Apex code must be covered by tests, your focus shouldn't be on the percentage of code that is covered.
- Instead, you should make sure that every use case of your application is covered, including positive and negative cases, as well as bulk and single record.
- This should lead to 75% or more of your code being covered by unit tests.
• Every trigger has some test coverage.
• All classes and triggers compile successfully.
Note:
Salesforce runs all tests in all organizations with Apex scripts to verify that no behavior has been altered as a result of any service upgrades.
What to Test in Apex
Salesforce.com recommends that you write tests for the following:
Single action
Test to verify that a single record produces the correct, expected result.
Bulk actions
Every Apex script, whether a trigger, a class or an extension, may be invoked for 1 to 200 records. You must test not only the single record case, but the bulk cases as well.
Positive behavior
Test to verify that the expected behavior occurs through every expected permutation, that is, that the user filled out everything correctly and did not go past the limits.
Negative behavior
There are likely limits to your applications, such as not being able to add a future date, not being able to specify a negative amount, and so on.
You must test for the negative case and verify that the error messages are correctly produced as well
as for the positive, within the limits cases.
Restricted user
Test whether a user with restricted access to the sObjects used in your code sees the expected behavior.
That is, whether they can run the code or receive error messages.
Note: Conditional and ternary operators are not considered executed unless both the positive and negative branches are executed.
Use of @IsTest(SeeAllData = True):
ReplyDelete------------------------------------
test methods don’t have access by default to pre-existing data in the organization.
To provide access to that data (From API 24.0 Version) We should use above method.