Gearset suggested Apex tests

Manual compare and deploy

When deploying or validating a package to Salesforce using Gearset, you're able to specify which Apex test classes you want Salesforce to execute as part of validating the package.

When you choose this option, Gearset will list all of the available test classes that are contained in the target org or in the package itself.

Here, because my package included the Apex class named MyClass, Gearset suggests that I probably want to run MyClass_T. It has based this on the _T suffix, which is one of a few patterns used to suggest tests based on naming convention.

The feature to automatically detect relevant tests is actively being developed, with the name-based suggestions being the most recent update. If you encounter any situations where we aren't suggesting a test that you would have expected, please let us know via the in-app chat and we make improvements where we can.

Continuous integration jobs

It is also possible to use the suggested tests feature when setting up a CI job.

With a manual compare and deploy, you're in a position to amend the suggestions - adding extra tests and removing those you're not interested in running.

When it comes to CI runs, there's no manual selection of tests, so it is important to know how the suggested tests are chosen. This will let you maximizechances of running all the relevant tests and achieving acceptable code coverage.

When is a test class suggested?

A test class will be suggested if one or more of the following criteria are met:

1. It is included in the package itself OR

2. It matches the naming convention OR

3. It references a class contained in the package

Tests in the package

If you are changing an existing test, or deploying a new test as part of your package, Gearset will include these in the suggestions.

Naming convention

If MyClass is included in the package, the naming convention will include any tests with the following names:

1. MyClass_Test

2. MyClass_Tests

3. MyClassTest

4. MyClassTests

5. MyClass_T

These matches are done case-insensitively; e.g. we will include MyClassTEST.

References to classes in the package

When Gearset needs to provide test suggestions, it makes a call to the Salesforce API and requests a list of all Apex classes and their associated symbol tables. These tables are used to identify if there are any test classes in the org that have a reference to one of the Apex classes being deployed.

Known issues and limitations

1. If you have a test that runs some Apex through triggers and does not reference the trigger class anywhere, we won't be able to pick this up through the reference-based method. The workarounds to this are:

   1. Make sure that the test class for the trigger matches the naming convention, e.g. MyTrigger tested by MyTriggerTests.
      

   2. If you can't do this, perhaps because there is a trigger manager pattern in use, then adding a reference to the test class will allow Gearset to identify that it should include the test class when that trigger class is included. This can be something as simple as adding private static MyTrigger forSuggestedTests; at the top of the class.
      

2. If Salesforce is already compiling Apex when Gearset requests the symbol tables, it will return null. This occasionally results in no tests being suggested, which in turn would mean 0% code coverage and a failed validation.
   
   To mitigate the issue, Gearset retries a number of times (currently ten). There is an increased delay between each try, to avoid any regularly timed compilations that may be happening in the org.
   
   There is no workaround should we reach the end of the retries, but the naming convention test will still apply as we do receive the class names even when we don't receive the symbol tables.

3. We only take account of direct references between the test file and the class it is testing. If you have situations where you expect the inclusion of class A to cause test class C to be run when C only interacts with A through one or more intermediate classes, then a reference to A would need to be added to C.
   
   Example

   1. MyClass is the only class included in a deployment.

   2. IntermediateClass uses MyClass.

   3. IntermediateClassTests are tests that target IntermediateClass.
      

Future improvements

Gearset development is guided by our customers, so please let us know if you have any suggestions as to how we could improve this feature. We are already looking into:

1. Caching to provide a fall-back to a failed symbol tables request, or to avoid making the request at all if we already hold a recent copy.
   

2. User-defined mappings to allow users to manually identify which tests should be included for particular test classes.