Edit: Summer '15 made this "all better". If you upgrade your ant-salesforce.jar to one that supports API version 34, you can now pass a "testLevel=RunLocalTests" attribute to sf:deploy like so:
<sf:deploy
testLevel="RunLocalTests"
username="${sf.username}"
password="${sf.password}"
serverUrl="${sf.server}"
deployRoot="src"
/>
From the docs:
http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_deployment_run_subset_of_tests.htm
As part of this change, the runAllTests deployment option is now replaced with testLevel. You can choose which tests to run in a deployment by setting the desired test level. For a description of all test levels, see test levels for the deploy() call. In particular, to run a subset of tests in a deployment, set testLevel to the RunSpecifiedTests value and specify the tests to run in the runTests option.
And
http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_api_meta_new_calls.htm#testlevels
RunLocalTests—All tests in your organization are run, except the ones that originate from installed managed packages. This test level is the default for production deployments that include Apex classes or triggers.
This was the workaround for pre-Summer '15 for posterity:
Because I killed off the better part of a day hacking around in ant to accomplish the workaround @pepefloyd suggested, I wanted to publish a working example; In my case, the test classes are prefixed with "Test_" but you can fool around with the fileset as necessary
This is tested against v30 of the Force.com ant migration tool
<target name="test">
<sfCompileAndTestUnmanaged checkOnly="true" username="${sf.username}" password="${sf.password}" server="${sf.server}">
<fileset dir="src/classes">
<include name="**/Test_*.cls"/>
</fileset>
</sfCompileAndTestUnmanaged>
</target>
<scriptdef name="sfCompileAndTestUnmanaged" language="javascript">
<attribute name="checkonly"/>
<attribute name="username"/>
<attribute name="password"/>
<attribute name="server"/>
<attribute name="trace"/>
<element name="fileset" type="fileset"/>
<![CDATA[
var filesets = elements.get("fileset");
var filesetsIterator = filesets.iterator();
var projectClasses = [];
while(filesetsIterator.hasNext()){
var fs = filesetsIterator.next();
var iter = fs.iterator();
while(iter.hasNext()){
var resource = iter.next();
var clazz = resource.getName().replace(".cls","");
self.log("CLASS: " + clazz);
projectClasses.push(clazz);
}
}
var task = project.createTask("antlib:com.salesforce:compileAndTest");
task.setCheckonly(attributes.get("checkonly") == 'true');
task.setUsername(attributes.get("username"));
task.setPassword(attributes.get("password"));
task.setServer(attributes.get("server"));
task.setTrace(attributes.get("trace") == 'true');
//I tried 'importPackage' and conventional instantiation but couldn't get the inner class to instantiate; this works though
var testsElement = task.getClass().getClassLoader().loadClass("com.salesforce.ant.CompileAndTest$RunTestsElement").newInstance();
task.addRunTests(testsElement);
var classClazz = task.getClass().getClassLoader().loadClass("com.salesforce.ant.CompileAndTest$CodeNameElement");
for(i in projectClasses){
var clazz = classClazz.newInstance();
clazz.addText(projectClasses[i]);
testsElement.addClass(clazz);
}
task.execute();
]]>
</scriptdef>
Alternatively, we've actually used a version of 'deploy' that does a no-op deploy (the package.xml in the 'ant' directory is empty except for the <version>
element. This gives us incremental updates as the tests are running and allows the deployment of the source files to succeed in a separate ant target (not described below) while the tests may fail (insufficient code coverage, failing assertions, etc.)
<target name="test">
<sfDeployUnmanaged purgeOnDelete="true" ignoreWarnings="true" username="${sf.username}" password="${sf.password}" serverUrl="${sf.server}" deployRoot="ant" maxPoll="75">
<fileset dir="src/classes">
<include name="**/*.cls"/>
</fileset>
</sfDeployUnmanaged>
</target>
<scriptdef name="sfDeployUnmanaged" language="javascript">
<attribute name="purgeondelete"/>
<attribute name="ignorewarnings"/>
<attribute name="username"/>
<attribute name="password"/>
<attribute name="serverurl"/>
<attribute name="deployroot"/>
<attribute name="maxpoll"/>
<attribute name="trace"/>
<element name="fileset" type="fileset"/>
<![CDATA[
var filesets = elements.get("fileset");
var filesetsIterator = filesets.iterator();
var projectClasses = [];
while(filesetsIterator.hasNext()){
var fs = filesetsIterator.next();
var iter = fs.iterator();
while(iter.hasNext()){
var resource = iter.next();
var clazz = resource.getName().replace(".cls","");
self.log("CLASS: " + clazz);
projectClasses.push(clazz);
}
}
var task = project.createTask("antlib:com.salesforce:deploy");
task.setPurgeOnDelete(attributes.get("purgeondelete") == 'true');
task.setIgnoreWarnings(attributes.get("ignorewarnings") == 'true');
task.setUsername(attributes.get("username"));
task.setPassword(attributes.get("password"));
task.setServerURL(attributes.get("serverurl"));
task.setDeployRoot(attributes.get("deployroot"));
task.setMaxPoll(attributes.get("maxpoll"));
task.setTrace(attributes.get("trace") == 'true');
//Blows up when build timeout is reached if we don't set this (it uses this value when formatting the exception it throws)
task.setOwningTarget(self.owningTarget);
var classClazz = task.getClass().getClassLoader().loadClass("com.salesforce.ant.DeployTask$CodeNameElement");
for(i in projectClasses){
var clazz = classClazz.newInstance();
clazz.addText(projectClasses[i]);
task.addRunTest(clazz);
}
task.execute();
]]>
</scriptdef>
The error log shows a number of errors in the metadata you're trying to deploy through the Metadata API which the Force.com Ant Migration Tool ultimately calls. My hunch is that a full save to server from Force IDE would get the same errors.
One thing I've noticed about deployment logs is that you can often ignore the massive number of duplicate lines. For example, the following error appears all over your log:
Error: Required field is missing: type
It's likely that a previous failure is causing this error and fixing the other failures will make this one go away. So, going with that strategy, there are a few errors you need to fix in the metadata files to get the deployment to pass:
[sf:deploy] 1. settings/Account.settings -- Error: You cannot disable account teams using the Metadata API. Your system administrator can disable account teams from the Account Team Setup page.
Account Teams are not supported for deployment through the Metadata API:
http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_unsupported_types.htm
[sf:deploy] 2. objects/AccountContactRole.object -- Error: ControlledByParent is not a valid sharing model for AccountContactRole
Adjust the sharing model of AccountContactRole.object or if you didn't make any customizations to it, delete the file locally so it's not a part of your deployment.
[sf:deploy] 3. objects/Site.object -- Error: Entity cannot be untracked.
This is likely due to the same issue with the same fix as discussed here:
https://developer.salesforce.com/forums/ForumsMain?id=906F00000008k09IAA
[sf:deploy] 163. objects/Contract.object (Contract.APXTConga4__Conga_Mail_Merge) -- Error: Cannot create a new component with the namespace: APXTConga4. Only components in the same namespace as the organization can be created through the API (line 235, column 15)
...
[sf:deploy] 171. objects/Solution.object (Solution.APXTConga4__Conga_Mail_Merge) -- Error: Cannot create a new component with the namespace: APXTConga4. Only components in the same namespace as the organization can be created through the API (line 120, column 15)
These errors indicate that you're trying to deploy metadata which comes from the APXTConga4 package. You can only deploy managed page components by installing the managed package. There is a trick you can do via the migration tool to install managed packages into the org as a separate deployment but covering that is beyond this question.
Edit the offending objects and remove any metadata starting with APXTConga4__
Finally, I wanted to point to another option I've been working with lately. You can create an unmanaged package in your sandbox org (Setup -> Create -> Packages) and then add all the custom code you want to migrate to it. Then you can use Ant to pull down only the metadata you chose to include in that package. This approach helps you avoid a lot of the issues you're seeing as it doesn't pull down anything from standard salesforce or installed packages, only the code you explicitly tell it to include. I plan to write a blog post on this approach soon, but you can get some more details from this answer I posted a few months back:
Using sf:bulkRetrieve do not fetch metadata components associated with a managed package
Best Answer
yes that is correct.
sf:compileAndTest
is no longer supported but you can run all test from sf:deploy task with the runAllTests="true" attribute, you don't need to actually deploy anything, though you will need a package.xml as per the documentation.Package.xml