What is Unit Test Coverage?

Let’s look at a simplistic, contrived example of unit test coverage. For demonstration purposes, the HelloWorld Class shows an Apex function that tests whether the text of a string matches “Hello World” or not.
// HelloWord Class

public class HelloWorld {
public static String isHelloWorld(String myString) {
if (myString.equals(‘Hello World’)) return ‘Yes it is!’; // Line 1
else return ‘No it is not!’: // Line 2
}
}

The verifyIsHelloWorld test method exercises our gratuitous example

// verifyIsHelloWorld test method

@isTest
private class TEST_HelloWorld {
static testMethod void verifyIsHelloWorld () {
String outcome = HelloWorld.isHelloWorld (‘Hello World’);
System.assert(outcome == ‘Yes it is!’, ‘Expected positive message.’) ;
}
}

At this point, we have 66% test coverage, because our test exercises only one of the two statements in isHelloWorld (line 1).

To bring test coverage up to 100%, we need to add another test method.

Why is test coverage important?

Salesforce.com has high standards for its own code and expects custom Apex code to also be robust and error-free. One of the best ways to increase code quality is to encourage developers to write unit tests. Witness a 2005 study found that unit tests increased both coder productivity and code quality.

While it’s possible for developers to boost code coverage with pointless tests, hardcore coders see unit tests as a way to release better code sooner – the keyword being “release”. The time spent on proactive unit testing is a trade-off with the time spent on reactive debugging. We can find our own bugs ourselves with unit tests, or wait and fix them later when a feature comes back with a QA ticket attached.

In my own work, I’ve found that the best way to ensure that code has adequate test coverage to practice test-driven development (TDD).

What is Test Driven Development (TDD)?

For the uninitiated, a classic way to bootstrap unit testing (and TDD) is to start with defect reports. Before fixing a bug, a developer first writes a test that proves that the defect exists. For example, if someone reports that isHelloWorld fails if we pass in a null string, we could start with a test like the one shown by verifyIsHelloWorldNull.

// verifyIsHelloWorldNull

static testMethod void verifyIsHelloWorldNull() {
String outcome = HelloWorld.isHelloWorld (null);
System.assert(outcome == ‘No it is not!’, ‘Expected negative message.’) ;
}

Since an exception counts as a failing test, we can proceed with the fix, say, by changing the code from:

| if (myString.equals(‘Hello World’)) return ‘Yes it is!’; // Line 1

to:

| if ‘HelloWorld’.equals(‘myString’) return ‘Yes it is!’; // Line 1

and maybe, for good measure, including a fourth test case for an empty string.

The key idea behind TDD is to “never write a line of code without a failing test”. If we are going to write the test anyway, better to write it first, code to the test, and receive full benefit for the time we invest.

How do we test code that doesn’t exist?

In an Apex environment, a unit test usually operates at the class level. To bootstrap testing a class or method that does not exist, we can start coding the test, create a stub class with stub methods, sufficient to compile the test, confirm that it fails, and then fill-in functionality to pass the test.

Let’s start over from scratch. First, we should define our requirements for the isHelloWorld method.

// isHelloWorld requirements

/**

• The isHelloWorld method determines if a String equals ‘Hello World’.
• (1) Given the String ‘Hello World’, the method returns “Yes, it Is.”
• (2) Given some other String, the method returns ‘No, it is not!’.
• (3) Given a null or empty string, the method returns ‘No, it is not!’.
  */
  
  
  
  Then, we can write a “happy path” test for the first requirement.
  
  
  
  // A happy path test for requirement (1)

final static String POSITIVE = ‘Expected positive message.’;
static testMethod void verifyIsHelloWorld () {
String outcome = HelloWorld.isHelloWorld (‘Hello World’);
System.assert(outcome == HelloWorld.YES_WORLD,POSITIVE ) ;
}

public class HelloWorld {
public static String isHelloWorld(String myString) {
return null;
}
}

public final static String HELLO_WORLD = ‘Hello World’;
public final static String YES_WORLD = ‘Yes it is!’;

public static String isHelloWorld(String myString) {
return HELLO_WORLD.equals(myString) ? YES_WORLD : return null;
}

final static String NEGATIVE =’Expected negative message.’;
static testMethod void verifyIsHelloWorldFalse () {
String outcome = HelloWorld.isHelloWorld (‘Hello Kitty’);
System.assert(outcome == HelloWorld.NO_WORLD,NEGATIVE ) ;
}

// Coding requirements (1) and (2)

public final static String HELLO_WORLD = ‘Hello World’;
public final static String YES_WORLD = ‘Yes it is!’;
public final static String NO_WORLD = ‘No it is not!’;

public static String isHelloWorld(String myString) {
return HELLO_WORLD.equals(myString) ? YES_WORLD : NO_WORLD;
}

static testMethod void verifyIsHelloWorldNull() {
String outcome = HelloWorld.isHelloWorld (null);
System.assert(outcome == HelloWorld.NO_WORLD,NEGATIVE );
}

final static String EMPTY = ‘’;
static testMethod void verifyIsHelloWorldEmpty() {
String outcome = HelloWorld.isHelloWorld (EMPTY);
System.assert(outcome == HelloWorld.NO_WORLD,NEGATIVE );
}

For requirement 3, we added two test methods, but did not need to change any code, since the current implementation passed the tests.

To fully test the method, we might also add a test for a string of maximum length, so that we test both boundaries. But, as it stands, we have 100% test coverage, and a test for each stated requirement, which meets my own personal “definition of done”.

Three takeaways from this exercise are:

• Never write a line of code without a failing test.
• Test every requirement, one requirement at a time.
• Passing tests give us the courage to refactor.
  In a followup blog, TDD with Apex Triggers, we look at how Test Driven Development works in practice, with a real-life non-trivial example.
  

A secret to the success of Salesforce CRM is how easy it is to customize and extend. Out of the box, Salesforce provides new users with a world-class framework for enabling collaboration between staff members and customers, or between staff and staff, or even between customers and customers (if you dare!). If that wasn’t enough, Salesforce provides a variety of ways to tailor your instance of the framework, so that it fits your own processes like a glove.

When folks first implement Salesforce, it’s easy to get carried away. Salesforce CRM can do so much, it’s tempting (but not practical) to try and do everything at once. In fact, Salesforce.com recommends that people spread out customization plans, so that refinement becomes an ongoing process.

Happily, two of the many Salesforce extensions include a project tracking app called “Milestones PM“ and a change tracking app called “ChangeIt“. You can use Milestones PM to organize implementation projects, and ChangeIt to gather and prioritize new change requests. Both can be installed into your environment from the Salesforce AppExchange, free of additional charge.

Milestones PM

Milestones PM is an elegant approach to project tracking that makes it easy to capture and follow a classic work breakdown structure. It’s a great fit for IT projects, but the app would work just as well for any type of task-based project, such as organizing a retreat, publishing a newsletter, or planning an office move.

The application uses six objects to track progress: Project, Log, Milestone, Task, Time, and Expense, as shown in the illustration.

Project is the top-level container for the other five objects. Aside from tracking key details – like a Kick-Off Date, Deadline, and Description – a Project contains a set of Milestones, along with an optional Log records.

Logs are generic memo records that you can attach to a Project, Task, Time, or Expense record. Logs can be used to capture any miscellaneous detail that doesn’t fit neatly into the other fields.

Milestones are the key organizing object within a project. To be useful, a Project must contain at least one Milestone record, which in turn can contain Task, Time, or Expense records. Milestones can have their own Kickoff and Deadline Dates, and be linked to Parent, Predecessor, or Successor Milestones. While not as featureful as Microsoft Project dependencies, good use of the Parent, Predecessor, and Successor Milestone groupings can make complex projects easier to understand and navigate.

The backbone of any project are the Tasks. Every Task must have a Name and be assigned to a Milestone, and can also track an Assignee, Start and Due Dates, statuses like Priority (0-4), Stage (In progress, Resolved, Closed) and Class (Ad Hoc, Defect, Rework), Estimates, and other properties.

Time and Expense records can be attached to Tasks, which are tallied as part of the Project’s overall metrics.

As shown in the screen shot, Milestones PM makes excellent use of native Salesforce metrics, and integrates with other native features like Chatter and Calendar It also supports batch operations based on views and comes bundled with two dozen ready-to-run Reports.

Even better, Milestones PM is an Aloha App, so it doesn’t count against the number of tabs or objects your Salesforce instance consumes.

ChangeIT

Like housework, a good Salesforce implementation is never done. The platform is so flexible and so deep, there will always be ways to make it work even better for your users. The ChangeIT application provides a vehicle for tracking new features and fixes (which you could then turn into Milestone PM tasks).

In a nutshell, ChangeIT provides a simple way to manage changes to your Salesforce instance, and to notify team members when changes are scheduled or implemented. It also helps coordinate change requests, so developers and administrators are not stepping on each other.

Saving the initial request triggers an approval workflow to the individuals that you set up. Once the initial request is approved or denied, the request can be worked on by developers or administrators (and/or transferred to Milestones PM). The application also includes a dashboard and supporting reports to view the pipeline of request changes.

Since the applications are independent, you can use either or both – your instance, your choice!

We’re always exploring better approaches to project tracking, with applications like Basecamp, Tom’s Planner, JIRA, and OnTime. Do you have a favorite tool? What features do you love? What features do you miss?

The Secret Life of Open Source

Apache, GNU, Mozilla, Ubuntu, PHP, LibreOffice, Wikipedia – Today, there are hundreds of open source groups, each with its own culture, methodology, and governance model.

• How are these groups alike?
• How are they different?
• Is there one true path to open source enlightenment, or do many paths converge around a common singularity?
  .NET at Apache.org

Like it or not, many open source developers are moving to the Microsoft .NET platform, and we’re bringing our favorite tools with us! This session looks inside ASF projects that are creating software for .NET and Mono – like ActiveMQ, Chemistry, Logging, Lucene, QPid, and Thrift – and show how to create leading-edge ASP.NET applications with ASF open source libraries. We’ll also look at integrating other .NET open source projects, like Spring.NET, NVelocity, and JayRock, into your C# application to create a complete open source .NET stack.

Before joining NimbleUser, Ted consulted with teams throughout the United States, including CitiGroup, Nationwide Insurance, and Pepsi Bottling Group, and he is a regular speaker at ApacheCon and the Ajax Experience. Ted is also a former member of the Apache Struts project and co-founder of the Apache (Jakarta) Commons. His books include Google Wave (Preview) Explained, JUnit in Action, Struts in Action, and Professional JSP Site Design.

As a Business Analyst for NimbleUser, Ted concentrates on identifying business needs and crafting solutions that meet an organization’s goals, objectives, and budget. Locally, he also serves as VP of Finance for the Rochester Chapter of the International Institute for Business Analysis (IIBA).

Create and update fields en masse (Tom Patros)

Using the supremely helpful Force IDE (an Eclipse plugin), Tom showed how easy it can be to mass edit fields properties via XML metadata. Developers already use the IDE to create and text Apex classes and triggers. Tom walked through how admins can use the IDE to quickly add or update custom fields by editing the XML metadata definitions the Force IDE generates. While easy to use, the Salesforce graphical user interface can become tedious when mass editing a set of fields, making editing via XML seem like a breath of fresh air. You can even manage picklist definitions by editing the metadata. For extra credit, Tom also demoed a Google spreadsheet that can be used to craft and document the schema, and then generate the definition to use with the IDE.

Connecting with SFDC API’s from Access (Bob Scott)

One of the most popular Salesforce admin tools is the Excel connector that makes it easy to manage Salesforce data directly from Excel. Bob Scott walked through how Access can be used to, well, access Salesforce data in much the same way. With a bit of elbow grease, you can update SFDC from an Access application, or update SFDC from Access.

Approval process simplified (Theresa Mason)

Often, an Opportunity or Quote needs to go through an approval process, and to make it through the gauntlet, certain fields must be completed. Getting users to remember which fields to fill out first can be a challenge, especially in the excitement of taking an opportunity to the next level. Theresa showed us how to add a validation to a checkbox, to trigger an automatic review of a record submitting it to an approval workflow. Great way to reduce many rules to one: Check the box and follow the instructions.

Synchronizer data mover (Rich Bilsback)

Synchronizer is a Microsoft Access database that helps you automate data tasks in Salesforce. Rich walked us through how he uses the Syncronizer to keep local application data updated, and how to use a local application to update your Salesforce data in the cloud. To get started, grab the Synchronizer from the Sales Force AppExchange. It’s a free “Aloha” application distributed by the Force.com Labs.

Stayed turned to the Rochester Salesforce User Group on Linked In for more Salesforce Thursdays coming this summer.