Sunday 24 January 2016

Apex Test Suites in Spring 16

Apex Test Suites in Spring 16

(Note that this blog post refers to functionality that is intended to be made available in the Spring 16 release of Salesforce, but features may be removed prior to the Spring 16 go-live date, so you may never see this in the wild!)

Introduction

One of the features that I missed most when moving from Java to Apex was the ability to create test suites. A suite is a container for a group of related tests, and is typically used to test a specific area of functionality. A common use case for me is around integration - when I’m making wide ranging changes I’m always keen to make sure I haven’t affected any of the code that integrates with downstream systems. Without test suites its either a case of manually executing individual tests and hoping I remember all of the tests I need, or running all tests and in some cases (e.g. our BrightMedia product) waiting 45 minutes for then all to complete.

While it has been possible to do this outside of the Force.com UI, there were compromises.  Using the Force CLI or Force.com Migration Tool (ant) meant that I had to execute my test suite from my laptop, while using the ApexTestQueueItem object meant that I either had to write code to create a new suite or install a package that allowed me to manage suites through a custom Visualforce page.The one thing all of my solutions had in common was a lack of flexibility to allow me to create a test suite and execute it on  any org at any time from any machine.

This all changes with the Spring 16 release and the introduction of test suites on the Salesforce Platform.

Using Test Suites

The easiest way to use test suites is via the Developer Console. I’m not the biggest fan of this from the perspective of authoring code, but its pretty much my go to tool now for running unit tests, mainly because it runs in the browser so I can execute tests on any org regardless of which device I’m using. 

In Spring 16 there are some new options in the Test menu for suites:

Screen Shot 2016 01 24 at 15 19 16

New Suite, as the name suggests allows you to create a new test suite. After specifying the suite name, you can then choose which classes make up the suite:

Screen Shot 2016 01 24 at 15 23 31

Note that you can’t specify individual test methods in a suite, so all methods in the class will be run when the suite is executed.

Suite Manager also allows you to create a new suite, or to edit (change the classes) or delete an existing suite.

New Suite Run allows you to execute a suite of tests. A nice feature for this is that it doesn’t limit you to a single test suite - you can choose multiple suites to run, creating a suite of suites if you will:

Screen Shot 2016 01 24 at 15 32 19

Note the settings button - this gives you access to another new feature in Spring 16 - automatically terminating a test run after a certain amount of failures. Specify the maximum number of failures through the resulting dialog:

Screen Shot 2016 01 24 at 15 34 35

As the number of failures allowed is 5, if 6 test cases fail, then test run will be automatically terminated. A synchronous test run terminates immediately, while an asynchronous test run waits until the currently executing test cases have finished and terminates once that is the case.

Once the test suite completes, the results are displayed as usual:

Screen Shot 2016 01 24 at 15 45 26

You can also run test suites via the API or version 36 the Force.com IDE, although bear in mind that if you upgrade to this version of the IDE you won’t be able to use it to work on any org that hasn’t been upgraded to Spring 16.

In a perfect world I’d like to see the following added to test suites:

  • Nesting suites - this would allow me to use my suites as building blocks, to assemble a super-suite from a set of component suites, or to extend (but not replace) an existing suite with one or two classes
  • Specify methods to execute in a suite - a bit more of an edge case, but this would allow me to create suites for particular aspects of a group of test classes - e.g. just the processing triggered when various types of sobject are inserted

Neither of these are a big deal, but one thing is a constant in software development and that is that everyone is a critic!

Related Posts

4 comments:

  1. Nice Feature and it will save time and keep us remember that we need to run this only and all our related changes in class will be cover.
    Thanks Bob again for this information.

    ReplyDelete
  2. Thanks Bob! I have a question, could you just have all your related test methods in one class? I am trying to understand what is the advantage of doing that v/s having a suite?

    ReplyDelete
    Replies
    1. You could, but then in my case I'd have about 400 test methods in a single class, which would be impossible to maintain. Test suites allow you to organise your tests to match the apex functional classes and still run a collection of them.

      Delete
  3. Your providing such a valuabe information about studying..and also have some good key points to every student.
    Salesforce Interview Question | Salesforce Training Videos

    ReplyDelete