Is there any advantage to using the older testMethod keyword to identify test methods or is it better to use the @IsTest annotation?

Does the location of these test methods have any significance? E.g. Either being included within the definition of the class being tested or defined in a separate class.

Attribution to: Daniel Ballinger

Possible Suggestion/Solution #1

As noted in the Apex Developer Guide on IsTest Annotation:

The testMethod keyword is now deprecated. Use the @isTest annotation on classes and methods instead.

So to answer your first question, there is now an advantage to using @IsTest rather than testmethod, namely that the former is still supported.

Attribution to: Adrian Larson

Possible Suggestion/Solution #2

As per developer Guide:

The testMethod keyword is now deprecated. Use the @isTest annotation on classes and methods instead. The @isTest annotation on methods is equivalent to the testMethod keyword

Note: testMethod doesn't have any impact on the count of apex character limit like it's mentioned in the other post the only thing here is that testMethod is now deprecated and @isTest the new one which we all should prefer going forward. I've tested this by removing testmethod code and there was no change in the character count of apex.

Attribution to: Ravi Roy

Possible Suggestion/Solution #3

From http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_qs_test.htm?SearchType=Stem

This class is defined using the @isTest annotation. Classes defined as such can only contain test methods. One advantage to creating a separate class for testing as opposed to adding test methods to an existing class is that classes defined with isTest don't count against your organization limit of 3 MB for all Apex code.

The advantage to using separate test classes is that they do not count against the limit of the total amount of apex in your org (although this is a soft limit and thus not a overly compelling reason).

You can also include non-test utility methods in classes marked as @isTest and (this is the compelling part) they do not need to be covered by tests themselves, and can only be called from inside of test methods! Very useful for data generation methods that are not needed in production code.

Attribution to: ca_peterson

Possible Suggestion/Solution #4

As @ca_peterson says @isTest doesnt count towards organization's total Apex code limit.

Here is the link for testing best practices. Just in case you need..

https://developer.salesforce.com/page/File:Apex_code_testing_webinar.pdf

Attribution to: Sathya

Possible Suggestion/Solution #5

I tend to agree with @ca_peterson in the use of @istest at the class level.

Using testmethod or @istest on the method level (within a test class) is interchangeable. You'll probably find yourself using @isttest more often, as that lets you specify the oninstall and seealldata attributes as needed (overriding the defaults).

But, if you have a bunch of test classes using the testmethod syntax, there's no reason to waste time changing them over.

Attribution to: kibitzer

Possible Suggestion/Solution #6

One reason you might co-locate the unit tests with the apex code itself is if you need access to private properties. This is something I run up against from time to time with Visualforce controllers, in that I want to inject some values into the private properties in order get the controller into the correct state to execute the test.

As stated above, this does count against the apex character limit, but I find its a trade off between that and writing code whose only purpose is to allow values to be stored in a private property when executing in the test context.

Attribution to: Bob Buzzard

Possible Suggestion/Solution #7

One benefit we've had from keeping the tests in a separate class is that you can have one engineer actively working on the class, while another is working on the tests. In an organization where development and unit testing are done by separate people, it makes coordinating your work (including using Git to manage your codebase) a lot easier.

I'll typically email my testing counterpart with my planned changes, and he can work on the unit tests while I'm working on the class. Either one of us can finish first, check code into Git, and wait on the other to finish before testing.

Attribution to: tomlogic

Possible Suggestion/Solution #8

I always use @isTest at the class level for the reasons stated in @ca_peterson's answer.

For individual test methods, I prefer @isTest, on the line above the method declaration, like so:

@isTest
static void TestSomething() { ... }

//instead of this:
static void testMethod TestSomething() { ... }

Why? If I need to disable a test, I can just comment out the @isTest line like so:

//@isTest
static void TestSomething() { ... }

And suddenly, the method isn't a test method anymore, it's just a "helper", and won't run as part of the test suite. This is handy if you're trying to isolate a problem in a particular test and want to temporarily disable a slow test, or tests that generate lots of log output. If needed, a quick seach/replace changes all test methods to non-test methods, and I can uncomment just the test I'm working on.

Attribution to: Jason Clark
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/739