Hi,

Testing is a formal process, to facilitate the development of robust, error-free code and
verify whether a particular piece of code is working properly or not. It should be a planned activity (NOT AN AFTER THOUGHT), test methods helps us deploy our Apex code to a production environment.  At least 75% code coverage is needed.

Writing test methods should be a critical part of Force.com development and they
are required to ensure your success. They also provide an automated regression testing framework to validate bug fixes or future development enhancements!

A test class should:

• Set up all conditions for testing.
• Call the method (or Trigger) being tested.
• Verify that the results are correct.
• Clean up modified records. (Not really necessary on Force.com.)

1. Understand the code you are testing. Know what it should and should not do.

2. Think of test cases as mimicing user interaction

Examples:

For triggers: They fire when a user inserts/updates a record. So to test, create the record and insert it and update.

This is where #1 comes into play. Know what the trigger is looking for or excluding. Create records that match both cases.

For a Class:

1. If class is called by a trigger, follow rules for the trigger.

2. If class is called by multiple things, set up the test to have records that cover the scenarios in the class. Then Instantiate the class and execute the methods.

For VF Pages: I really have found no need to set references to those unless the controller actually looks at the elements or parameters or has a constructor that needs the controller of the page to have coverage.

Basically, just think of it on two levels:

1. Mimicing what happens

2. Testing for appropriate responses to specific positive and negative use cases.

**This is where MANY developers go wrong. They write the test code to cover the lines but NEVER check to see that what was expected to happen actually did. Do this by using systemAssertEquals and system.AssertNotEquals

Once you get the basic understanding down, writing test cases becomes easier. They do come with their own set of rules, quirks, etc...... Oh, and Not sure if others find this, but good test cases average me about 3 lines of test code for each line of actual code written. It takes me longer to write the test case sometimes than it does to write the actual code...

Did this answer your question? If not, let me know what didn't work, or if so, please mark it solved.