I’ve been fortunate to have worked as a consultant Salesforce architect for the last decade, during this time I’ve encountered an interesting variety of approaches to Agile in the Salesforce space – most of which fitting with the hybrid model unfortunately – what has been noticeably absent is the application of agile engineering practices. Test Driven Development (TDD) is one of most widely understood agile engineering practices (alongside Pair Programming) – and is perhaps the most practical to adopt, however despite the benefits, despite the level of lip-service paid to the subject in practice TDD remains a rarity. With this post I hope to provide a convincing argument to Salesforce developers and architects that TDD does not add overhead to the development lifecycle and in fact the opposite is true. The Salesforce platform in development terms is maturing, the introduction of new tools and techniques such as Salesforce DX (SFDX) are testimony to this. In this context, the idea of developers working ad-hoc and in an undisciplined manner doesn’t fit, instead the consistent application of established engineering practices will play a key role moving forward. No more low quality unit tests (written as an afterthought) and no more random coding conventions and inconsistent standards. Salesforce development teams can no longer choose to hide in the void that sits between declarative development and traditional software engineering, it’s definitely time for some new habits.
This blog post draws together a high-level conceptual view of Test Driven Development with the implementation practicalities unique to the Salesforce platform.
Let’s start with great quote to set the scene.
“Build it right to build the right thing“, Ron Jeffries. The concept is simple; build the product right, repeat until it’s the right product.
Test Driven Development
Test Driven Development is an XP agile engineering practice. eXtreme Programming (XP) is a software development methodology focused on customer value, continuous feedback, incremental feature delivery and team empowerment. It is a widely recognised fact that the earlier testing is applied in the software development lifecycle – the greater the value (shorter development timescales, more reliable code etc.). TDD takes this idea to its ultimate conclusion where testing occurs in front of actual coding. This may seem counterintuitive. In order to understand the impact of this fully it’s important to understand the high-level approach.
(1) Identify a low-level requirement (PBI, Task etc.)
(2) Describe the logical tests necessary to confirm that code satisfies the requirement
(3) Write the minimum code necessary to pass the tests
(4) Tidy-up the code to remove clutter, complexity and duplication
The steps above describe a design process where software evolves in very small increments with a focus on simplicity and testability. This step-by-step approach results in emergent design, where the code informs the design approach and guides the developer toward the best solution. This is the direct opposite of the traditional big-design-upfront (or BDUF) approach. The goals and benefits of TDD are many; “clean code that works” is a phrase that best summarises this (another golden Ron Jeffries quote). Note, TDD is often referred to as Test Driven Design in recognition of this emergent design side-effect.
TDD Cycle
It is imperative to understand the conceptual aspects of TDD in order to gain the full benefits, thankfully the practical application follows a relatively straightforward and approachable 3-stage cycle (Red-Green-Refactor).
Stage 1 – Red : Write the minimum code needed for a failing test. This may entail development of (or extension to) a test harness, plus the unit test code required to exercise the logical test case. The test code could be completely new or simply an augmentation to existing tests. In writing the test code the developer is forced to think through the requirement in detailed, logical terms – the type of thinking more typically applied at a later stage when writing the functional code.
It is imperative that test code evaluate predictable logical test conditions. The test code should fail for a specific, expected reason – not due to a test harness issue or due to the fact the test code itself is invalid.
Stage 2 – Green : Write the minimum amount of code needed to pass the test. The code written here must satisfy the test condition and nothing more – no embellishments.
Discipline is required to avoid the developers innate tendency to create.
Stage 3 – Refactor : The functional code should be reviewed and modified to remove clutter, complexity and duplication. Code should work (of course) but also (critically) be readable, updateable and testable.
Clean code is the objective here; if every tiny incremental addition of code satisfies the clean code criteria (readable, updateable and testable) the outcome will be a highly organised and easily maintainable code base that can be extended with new features at a consistent level of effort over time. Where such an approach is not applied it is often inevitable that a complete re-write becomes necessary once the steadily increasing incremental cost (time) of adding new features becomes intolerable.
The TDD cycle then repeats over and over until all requirements are addressed. The incremental design approach focuses upon each individual requirement one at a time. This minimalist, simple design lead approach can be difficult for experienced developers to adopt, however once the learning curve is addressed the focus on simpler designs allows easier modification, more efficient testing and faster production.
TDD in the Salesforce Context
The Salesforce (or Force.com) cloud platform is an ideal software development environment in which to adopt the Test Driven Development (TDD) agile engineering practice. The Apex programming language has integrated unit testing capabilities which reduce the level-of-effort required. Salesforce Developers are also accustomed to the idea that code requires a (platform enforced) test coverage level of 75% for production deployment. In the Salesforce development context therefore the tools are provided and concepts relating to unit test development well understood. The only challenge remaining is the mind-set shift from big-design-upfront and retrospective test code development to TDD and the agile benefits of emergent design, clean resilient code and reduced development effort.
Unit Testing on the Salesforce Platform
An Apex class can be easily annotated (@isTest) to indicate its role as a unit test class. The snippet below shows a very basic example.
[code language=”java”]
@isTest(SeeAllData=false)
private class FeatureTestClass {
@testSetup static void setup(){
// populate custom settings.
// create test data used by all tests.
}
/* **/
static testMethod void isAccountProcessed() {
// setup test specific test data and context
insert new Account(Name=’Acme Inc’);
Test.startTest();
// do something
AccountProcessor.process();
Test.stopTest();
// test outcome
System.assertEquals(1, [select count() from Account where IsProcessed__c=true]);
}
/* */
}
[/code]
The [SeeAllData=false] flag indicates that only test data created by the class is visible to the test method (plus some actual data; products, users etc.). There are circumstances where the flag must be set as [SeeAllData=true] flag, where test code is unable to create required test data due to object access permissions. The isTest annotation takes a second parameter [isParallel=true|false] which controls whether the test class can run in parallel with other tests (for expedient execution) or whether the behaviour requires serial execution (perhaps to avoid lock contention on shared resources such as custom settings).
Once a test class is implemented, adding individual tests becomes very straightforward. A standardised naming convention for the test cases can help the readability of the code; perhaps based on the expected outcome or the logical test case. Test code organisation at the class level should also be predictable and may follow a feature convention.
There are a number of methods available for the execution of test code on the Salesforce platform; Setup menu, Developer console and API (incl. IDE) as examples. Tests can also be executed asynchronously at a scheduled future time via Apex or the API (ApexTestQueueItem, ApexTestResult objects).
As the screenshot above shows the developer can configure a test execution to include all or selected test cases from multiple test classes. In the context of the TDD cycle the developer requires the ability to run just the one test case – not all, this would waste time.
Test Suites allow test classes to be grouped and executed together; this can be seen in screenshot below.
In the TDD context, where unit tests drive the development process it is important to have a clear naming convention defined for:
Test Case: expected outcome, or logical test case (readability is key)
Test Class: group of test cases relating to a given feature
Test Suite: group of test classes relating to a functional area
What is a Unit?
For the TDD cycle to be effective it can help to understand the level at which a unit test is applied. A unit is variably defined as the smallest testable part of an application, or the smallest change that still makes sense to be tested in the developer’s opinion. This of course is a subjective definition.
Common sense should be applied; a 200 line Apex trigger on Account will not be a single unit, a 20 field update on Contact also won’t be 20 units. Instead the feature being developed should be decomposed into a unit test per logical test case. This can take practice to get right, but striving to keep each test as simple as possible should be the primary guiding factor. Simple tests are easy to modify and provide a self-documenting benefit.
Advanced Unit Testing
The Apex language supports the advanced unit testing technique of Mocking which enables isolation of test execution from external factors such as API callouts or Salesforce configuration changes.
Mocking essentially involves the non-disruptive, dynamic substitution of a test specific class instance in the place of a functional class instance. Apex provides the HttpCalloutMock interface to allow test code to utilise pre-fabricated Http callout responses. The Stub API (StubProvider interface and Test.createStub method) supports the development of Mocking frameworks that enable any class to be substituted dynamically at runtime.
References
Apex Developer Guide > Testing Apex