function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
StatBoyAStatBoyA 

Best Location for Test Methods?

In the past, I've typically separated test methods into a separate Apex class. 

 

Although I've had no particular problems with this, I'm now thinking that it might make more sense that test methods be included in the same class that actually implements the functions being tested. 

 

I wonder if the long-experienced coders here have any strong preferences one way or the other?  Test methods WITHIN the class being tested, or in a SEPARATE class devoted only to "testing" code? 

 

I'd also love some explanation of the practical benefits/detriments that have been experienced with either approach...

 

Thanks much.

 

 

Cory CowgillCory Cowgill

I prefer to write them in a seperate Test Class, one seperate test class for each Class. Always denoting the test class by naming it the same as the class being tested with "Test" at the end. For example, AccountTriggerHandler and AccountTriggerHandlerTest.

 

I like this approach for a few reasons:

 

1. This keeps a clear seperation between application logic and test logic. Your classes don't get bloated with testMethods.

 

2. I always try to create multiple, discrete testMethods which test specific functionality. Many times I see developers write one huge test method, which is a mess in my opinion. If one assert in that huge method fails, its a pain to debug. I like to create multiple test methods with clear test method names for what I'm testing. For example. accountTotalFeesTest and accountMonthlyRatingTest. Having this done in a seperate class makes it easier when tests fail to identify the exact issue. Doing all this in one class again makes the class get bloated and long.

 

3. If you using a version control system outside SFDC, you can checkout, checkin the Test Code without modifying the Application Code. This helps you clearly see what actual business value changes were done versus a long line of test method changes to improve coverage, etc.

 

4. You can deploy updated unit tests without deploying the application logic classes.

 

Those are my opinions anyway.
StatBoyAStatBoyA

Cory,

 

Thanks for sharing your thoughts...

 

Well, I especially like the idea of deploying improved tests WITHOUT a need to re-deploy the functions being tested.

 

And the basic logical "feel" of a test/function split seemed appealing to ME from the outset.  But I'd never really asked, nor seen a clear discussion about this.  And it started to seem very prudent to at least ASK... .

 

Still interested in other perspectives if anyone cares to offer them...

 

 
bob_buzzardbob_buzzard

I tend to be ambivalent about this.  While having tests in separate classes is good practice, co-locating the tests with the code allows access to private properties/methods, which means that these items can be tested in isolation, rather than relying on the public methods to exercise them.  

 

I also tend to include tests for Visualforce controllers in the deployable class as I think it makes it easier to figure out what's going on, but that's an entirely personal preference with no basis in fact :)

 

I couldn't agree more about the huge monolithic unit tests that try to cover everything in one method.  If the test breaks early on, you've no idea how many more problems are waiting for you!

 

Another technique I use a lot is that of a unit tests helper class - this is a class that provides methods for instantiating objects among other things.  The benefit of this is that if you add a required field/validation rule, you only have to change one piece of code for every unit test to be able handle it.