Is Your Code Green?

By Alan Shanahan – Principal Technical Architect for Astadia Consulting

Alan ShanahanNow when I say Green, I don’t mean the ‘Eco-Friendly’ type of green. What I’m referring to is the type of code that, when tested, comes back with zero errors

Here’s a real-world scenario I’ve come across more than once. You engage a consultancy firm to add some additional custom functionality to your org. They develop new Visualforce pages, along with some Apex code classes and triggers to give you what you need. After testing you’re happy with the new functionality and press on for production; then bang! The problems start!

Suddenly, they’re asking for more time (and money) to make changes to your existing codebase so they can deploy their newly-developed functionality into your production environment. You stand bemused, searching for reasons why on earth would that be the case? The people who developed the last set of custom programs deployed theirs without any problems, and you haven’t touched a line of code on the system since; you couldn’t have, nobody in the organisation knows how to!

So, what happened? Gremlins? Industrial sabotage? Inquisitive amateurs? Hackers?

Most likely none of the above. Perhaps you unwittingly caused the problems yourself.

Let’s dig a little deeper to discover why…

Firstly, let’s look at test methods. What are they? Put simply, test methods are a set of programs that (if built according to best-practice guidelines) create their own sample data, establish test conditions for your Visualforce pages, Apex classes and triggers, create events that run your code through as many test scenarios as possible, to check that various test results match expected results, and put up a metaphorical red flag if any failures occur. In short, they are programs that test other programs.

From the point of view of, you need to “exercise” at least 75% of your entire Apex codebase, and have no program failures occurring on ALL test methods in that codebase in order to deploy code to a production org. This is a hard-and-fast rule, and there’s no way around it, and for good reason.

In light of an excellent article that delves quite deeply into the whole subject, rather than have me rabbit on for pages, I suggest taking a look at this:

As business users work with their org, it’s not uncommon for them to find a case where users have entered erroneous data. To combat this, System Admin creates a new validation rule in the production org to ensure a phone number is now mandatory where it had previously been optional. The business continues without a hiccup, data quality is improved, all is well…

Except for one thing – the assumptions around business rules have changed and the developers were not informed, so any test methods that were creating test data in this functional area would have left this phone number field blank. As soon as the test methods attempt to write data to the database, program failures occur because of the new validation rule. In reality, there is no real problem yet because test methods don’t run until a developer asks them to run. It’s not until someone attempts to deploy new code to the production environment that problems occur.

On the face of it, there’s nothing really wrong with adding this validation rule, in fact Salesforce makes it easy to do this. However, there’s a strong argument against changing any component that has an effect on a system’s business rule implementations without going through the proper regression and acceptance testing. The fact is that your codebase, and its collection of test methods, if properly written, should form a sound basis for any regression testing that you carry out, which can be used to help identify just this type of scenario.

Except during times when development is taking place (and only then for short periods), all of a system’s test methods should be in GREEN status i.e. they should all run without failure and with the appropriate amount of code coverage. Above all, system tests should exercise all your code thoroughly and check for positive and negative conditions as much as possible.

To check the status of your org’s code, simply do the following:

  • Log into as an Administrator (or a user with similar permissions)
  • Click the Setup link, top-right of the page
  • On the menu at the left, under the App Setup section, click on the Develop heading
  • Now click on Apex Classes and you will see a list of class files in your system

The magic button is the Run All Tests button. Click it and stand back. This may take a few minutes depending on the amount of code to run but when it’s finished you will have quite a lengthy web page with detailed debugging information. We’re only interested in a small part of that though, at the top. It’s the figure next to Test Failures – if it’s zero, you’re in clover, Green! If not, something has changed and now there’s an additional element of risk to your next custom development project.

Don’t despair though. Quite often the code corrections are minimal. But one thing is sure, you do want someone with the appropriate expertise to carry out this work. Astadia Consulting can help with this. Just contact us at or email us at and we’ll organise a code review and give you a comprehensive written report to prepare you for your new development project. We can also talk to you about TDD (Test-Driven Development) and best practice for the entire subject area.

0 Responses to “Is Your Code Green?”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 28 other followers

Astadia EMEA on Twitter

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Our Authors

Previous Blog Posts

<span>%d</span> bloggers like this: