Testing Best Practices - II

Testing Best Practices

Here are my top testing best practices with Salesforce.com that I learned on the job.

Write fully portable tests

When you write your tests, you do so in the context of a Developer or Sandbox org. You can write tests that rely on specific pieces of data, user accounts, server names, etc. If you do that, however, your tests will fail on deployment because those things will be different in the destination organization.

Use relative URLs and query for names of data records rather than their specific Ids. Then if your tests pass in the sandbox, they are more likely to behave as expected no matter where you put them.

Don’t use production data in your tests

On a related note, if you do SOQL statements in your tests, those queries will return results from the Salesforce instance. So, if you SOQL “Id from Account where Name =’HOTAS’”, you will get one result in Sandbox and another in Production. When you set up test data, make sure to use names that will never show up in production, like “HOTAS_for_tests” as an example Account Name.

Test expected behavior first, then test unexpected behavior

Start with testing simple cases, and test to make sure that what what you expect to happen is indeed happening. Then make sure to add test cases for behavior you don’t expect, but could happen. This is why they tell developers never to write their own tests, because we all believe our code will behave as expected. Fight that urge, and test around the edges to make sure you’re covering yourself.

If you find a bug, write a test to expose it before you fix it

When someone reports unexpected behavior in your code or UI, write a test that will find the bug and fail. Then fix the code until the test passes, and leave the test in. By putting the test in there first, you’re doing test-driven development for this fix, which is a great practice to get into. If you leave the test in there, you’ve also now got a regression test in case you accidentally reintroduce that bug later.

Shoot for 100% coverage

Try to test everything. It’s not always fun or even possible, but try.

Don’t rely on Today()

If you are using dates in your code, don’t build your dates on Today(). Rather, use something like Date.newInstance(2005,10,10). By putting a date in the past, you don’t have to worry about what will happen to your test when you try to run it on February 29th, or the instant we hit daylight savings time. If you think those cases will affect your code materially, you should specifically test those cases, but most of the time you’re safe to ignore that by not using Today().

Put your tests on the controller and class, not in separate classes

We’ve found it easier to ship code around when the test methods are on the controller classes. It’s fewer files to keep track of, and when you deploy to production, you’re tests are automatically included in the package, ensuring code coverage.

Please comment if you’re interested in having a discussion about testing in Salesforce.com. I love and hate that they require 75% code coverage for deployment to production–it sure pays off in the end, but it can be quite a drag w