As a Force.com developer, you are probably already aware that before you can deploy your code into production, you should have atleast 75% test coverage. Though necessary (since the platform enforces this requirement), it is hardly sufficient to ensure that your code meets the requirements and expectations of the users. I will briefly describe the different types of testing you should consider before rolling out a Force.com application.
Unit Testing – Unit testing is used to verify that each individual piece of code (trigger, a method of a class, custom controller code etc.) is behaving as expected. Force.com provides a testing framework which helps in the creation and execution of such unit tests. This article provides a great overview of how to write and execute such unit tests. As mentioned earlier, the platform enforces that atleast 75% of your code has test coverage before custom code can be deployed into production. Unit testing can be done by individual developers either in their developer sandboxes or DE orgs. Since these tests are run in the production org before the code can be deployed, it is important that these unit tests are self contained i.e. not have any dependency on data that may exist in a particular org. Also see Apex Test Coverage Best Practices for a good coverage of best practices for writing unit tests on Force.com.
Integration Testing - The goal here is to test the interface between the different units of code. This testing can be done in a configuration only sandbox or a developer sandbox with some sample data. Integration testing will surface any mismatched assumption made about the behavior of code that need to talk to each other.
System Testing – This is testing that is conducted on the complete, integrated system to verify that all functional requirements are met. The system is treated as a black box and along with the functional requirement, performance testing and security requirement verification should also be carried out. A full copy sandbox provides the best environment for system testing.
User Acceptance Testing - This is the final step before rolling out the application. The end users who will be using the application should have the confidence that the application meets their requirement. Most of the bugs should be fixed before you roll it out for User Acceptance Testing. The focus is on usability of the application rather than the technical implementation. This test should be carried out on a full copy sandbox since it simulates the production environment.
These tests should be fully described in your test plan. A test plan is a comprehensive document that describes the objectives and scope of testing, the stakeholders, the testing methodology and tools used, the metrics that will be captured and the testing schedule. It should be a living document that has the active participation of all the stakeholders. If you are a consultant implementing a system for your customer, you should have a formal sign off process.
Let's look at a few best practices….
- Have a testing strategy and a test plan document.
- Address all the different types of testing as described above.
- Do not push testing to the very end – testing shouldn't be seen as a check mark item that stands in the way of deploying the code but rather as a way of improving the software quality and verifying that the end user expectations are met. We recommend using a test driven development methodology
- Plan and schedule any resource dependencies ahead of time – the resource dependency may be end users who have to do acceptance testing or access to some external system to do system testing. If there is any change in schedule communicate to all parties involved as quickly as possible and agree on a new schedule.
- Test early, test often – a bug caught earlier in the development cycle is cheaper and easier to fix vs. if it is discovered later in the cycle.
Finally, don't forget to budget time and resource to develop and execute on a test plan. Though there may be a temptation to just push the code into production and hope for the best, experience with numerous software projects has shown that it rarely works.
