While the ideals are good, there are many challenges preventing an organization from reaching these goals. Managers may not fully understand the benefits of unit testing, and as a result have little or no buy-in for the practice. Without buy-in from managers, there is no enforcement of consistent methodologies for internal and external developers. Frustrated developers who don't have management support, training or knowledge on unit tests only see the code coverage portion of unit testing and feel that the practice is a big pain with little gain.
But actually, proper and disciplined use of unit tests on Force.com allows a company to:
- More reliably implement new features by explicitly testing for expected functionality using Apex
- Simplify regression testing by allowing the system to automatically perform acceptance tests that were used when deploying previous features to production
- More confidently allow developers to simultaneously tackle multiple work streams for different features, knowing that both each other's functionality and previous functionality will be validated together before new features goes live
- Define functional specifications for external parties through unit tests, in addition to written requirements
This blog mini-series aims to address the challenges above by sequentially tackling the following topics, with new posts every 3 business days:
- Standard pattern for Apex unit tests
- Common database of test data for all Apex unit tests
- Using System.assert() and related methods to verify expected conditions for the test
- Using Test.startTest(), Test.stopTest() and other Test methods
- Using System.assert() and related methods for validating test results
- Apex unit tests for workflow rules, validation rules and system configurations
- How this standard pattern affects code coverage
