Salesforce Testing Disasters


No Cheating

All too often I am engaged to help Salesforce customers who are struggling with significant quality issues with their custom code.  Here are some lessons learned from the most spectacular disasters I’ve had to remediate. 

If you are responsible to manage a Salesforce implementation read the full content of my post on LinkedIn to learn how developers can (and do) deliver deceptive indicators of code quality by:

  1. Cheating the 75% code coverage threshold
  2. Implementing test classes which test nothing (other than coverage)

See http://www.linkedin.com/pulse/salesforce-testing-disasters-richard-clarke 

What will you learn?

  1. Code coverage is not a useful measure of code quality
  2. Even 100% code coverage can be meaningless if the test code does no “testing”
  3. Code coverage can be cheated on by adding fake classes (and yes sadly I've seen this in production Salesforce instances)
  4. Test methods passing are meaningless if the test does no testing
  5. User acceptance testing via the UI is not enough if only the simple positive use case is tested
  6. Developers can be lazy or plain deceptive whilst giving the appearance of providing good code

Recommendations:

  1. Document test cases (acceptance criteria) up front
  2. Ensure test cases cover positive and negative scenarios
  3. Ensure test cases bulk data manipulation
  4. Direct the developer about what automated tests must be implemented
  5. Follow test driven development principles and create the test methods FIRST
  6. Ask for an independent expert review if you are struggling with code quality

Richard Clarke

Richard has been delivering complex integrated solutions on the Salesforce platform since 2007 and is the Melbourne based principal consultant for FuseIT Australia.
https://au.linkedin.com/in/richardaclarke
 

Comments are closed.