Trapdoor In The Sun

Alan Shanahan, Technician & Consultant

1 Comment Apex Test Assertions: It Must Be a Real Test

In the course of building automated tests, it’s always good practice to pepper your test code with Assert statements to ensure your code is functioning as you would expect throughout. But, as I’ve seen more than one example of the specific behaviour in the first code section below, I think it’s something I should point out.

On first glance, it looks like the assertion is doing the right thing. But if you think about it, it’s not a real test. It only tests that the in-memory variable testAcc.Name has the value originally assigned to it a couple of lines back.

// Example 1. An in-memory-based test
Account testAcc = new Account();
testAcc.Name = 'Testing 123';
insert testAcc;


What it really needs to do, so that it becomes a “real” test is for the test method to query the database record just inserted and to retrieve the Name value from the record, then check it against the expected value, as shown below.

// Example 2. A database-based test
Account testAcc = new Account();
testAcc.Name = 'Testing 123';
insert testAcc;

Account checkAcc = [SELECT Name FROM Account WHERE Id = :testAcc.Id];

This example is, perhaps, not a great real-world scenario but I feel it illustrates the problem well.

Happy coding, if it’s your thing.

Leave a comment

Help, The Internet Isn’t Working

Please Help Me

“The internet is not working.”
“My computer isn’t working.”
“That program doesn’t work properly.”.

If you’re asking someone for help and you think this is useful information, then you really need to try harder. Most of those who have spent time supporting others will have heard lines similar to these at least once. It’s the equivalent of someone throwing their arms in the air and say “I don’t care how you do it, just fix it”, and it’s hard to take. This is bad enough when it comes from self-confessed, even proud, Luddites. But when it comes from other technicians, it is hard to forgive.

Often it’s because they have no experience of supporting users themselves and cannot perceive of the viewpoint of the person coming to their rescue. It screams loudly “I am not prepared to invest a moment into this, I just want it to work”, and much of technology just isn’t like that. If it’s man-made, it’s fallible and things go wrong.

Consider the first phrase above: “the internet is not working”. Apart from displaying a high degree of ignorance, it isn’t helpful in the slightest. You can glean from that phrase that someone has a problem browsing the web. Because the “web” and the “internet” are the same thing, right? There’s the first problem. Let’s assume there’s a problem browsing the web; how does the problem manifest itself? Is the web page slow to load? Does it load at all? Is there a visible error message anywhere? Before wasting your support person’s time, look closely at the problem. If the web browser says “HTTP error 404”, pass on that information. What web page are you trying to access? Pass that information along. What web browser are you using, Internet Explorer, Chrome, Firefox? Tell the man! It’s all useful information. Are you able to access another web page, one you know works, e.g. Let him know. Is your WiFi connection active? Can you access any other internet services, e.g. email? Can you send messages? Can you receive? This is all useful information and accelerates your support person’s ability to resolve your problem.

Where To Start

From the support point of view, it’s all about having a decent starting point. A succinct, clear description of the problem, some supporting information. From there, it’s a game of elimination. There are many components in this problem; the technician has to think about “the chain”. What is the chain?

Computer -> browser/email client -> firewall -> wifi, if any -> cables, if any -> router -> incoming cabling -> ISP -> DNS servers -> web server

This is a simplified chain to make the point. Look at any one of those points of failure and think about how many possible faults there are. The number is quite large. It needs to be reduced. Giving additional information like “I cannot access my email” or “I can see the BBC news web site but site X pages aren’t loading” is very useful. It shows that the computer, browser, connection, router, incoming cables, ISP and DNS servers are all working and that the problem may lie at the web server side or email server of things. The techie asks “what URL did you type”, “how are you trying to access the web site” or “show me your POP3/SMTP settings” and discovers that the user has typed in the wrong URL or has a misconfigured email client. Without this extra detail, the user has to check each component above until he discovers the point of failure. Each link in the chain could force many questions and take a lot of time.


The central message of this post is not just for users of technology, it’s for designers too, at all levels. Give users the visibility they need to help you to help them. Consider how they have visibility of your system and how they can extract useful information from it to help you support them. Everyone stands to gain from this.

Leave a comment Visualforce; slightly better field declarations

Soft coded = good. Hard coded = bad. That’s difficult to argue against and I doubt there’s much dissent in any programming community.

Define it once, use it many times; this is part of the reusability principle that applies to code segments and text literals. When you define an input field in a Visualforce page, more often than not it is based on a field that exists somewhere in the database. It makes a whole lot of sense to take as many attributes from the original field definition as possible, so below are some examples of how you might do that.

(1) When defining a field on a page, prefix it with its label. Use this syntax:
…where ObjectName__c and FieldName__c should be replaced as appropriate.

(2) Use the field’s own help text by referring to the InlineHelpText attribute, as shown below in this syntax:
…where ObjectName__c and FieldName__c should be replaced as appropriate.

(3) Limit the field length in HTML during data entry by using this syntax:
…where ObjectName__c and FieldName__c should be replaced as appropriate.

<apex:pageBlock id="searchPageBlock">

	<apex:pageBlockSection columns="2"
	 id="searchPageBlockSection" title="Global Search" collapsible="false">

		<apex:pageBlockSectionItem id="searchAirport"

			 value="{!$ObjectType.Airport__c.Fields.Airport_Name__c.Label}" />
			 onkeypress="return noenter(event);" />


The above code works well for text input fields. If you need information on numeric or other input field types check out the $ObjectType schema information page.

4 Comments Visualforce programming, position cursor at first input field

When building a custom Visualforce page with input fields, one common requirement is to place the cursor at the first input field on the page. You would think this would be a simple matter and Salesforce itself manages the task quite well. But when the platform’s default behaviour kicks in and overrides your page’s behaviour, it doesn’t always work smoothly. Or if you want to position on an input field that is not a text entry field it doesn’t always slide into place. Or perhaps you wish to show a dialog box where you wish to conditionally position the cursor to a Confirm or Cancel button depending on prior processing.

In this piece, I’m offering a foolproof way to enable your page to behave exactly as you want it to, in an easy, maintainable way. Here is the step by step way to do this.

First, download a copy of the JQuery library from The minimised (compressed) version is just fine.

Now, upload it to your Salesforce org as a Static Resource.

In your Visualforce page, add this line somewhere after the apex:page tag:

<apex:includeScript value="{!$Resource.JQueryJS}" />

…making sure to replace the JQueryJS text with the name you specified during the Static Resource upload step.

The code below assumes that the page is aware of a “mode” or action passed to it, perhaps as a querystring parameter and parsed separately into a variable called wrkAction.


	<script language="JavaScript">

	// JQuery initialisation
	j$(document).ready(function() {

	function initialisePage() {
	function positionCursorToFirstField() {
		if ('new' == '{!wrkAction}' || 'edit' == '{!wrkAction}' || 'copy' == '{!wrkAction}') {
		if ('del' == '{!wrkAction}') {

The page buttons might be defined later in your page code, as follows:

	<apex:pageBlockButtons id="pbButtons" location="bottom">
		<apex:commandButton id="btnCancel"  value="Cancel"  immediate="true" onclick="return checkCancel();"  />
		<apex:commandButton id="btnConfirm" value="Confirm" immediate="true" onclick="return checkConfirm();" />

Given that any page element will probably exist in the hierarchy of page elements, the Visualforce page is rendered with the implicit naming applied i.e. the full “pathname” to the element is implied in the name, with colons separating each branch in the tree. For example, an HTML id such as j_id0:j_id1:j_id192:j_id193:j_id196:j_id230:j_id231:j_id232:4:j_id236 would not be unusual.

The above code brings a “best practice” tip to mind – always use page-unique ID values for input fields, buttons and all other page components. Specifying the ID tag also ensures that the implicit naming conventions are not applied.

The JQuery code in the positionCursorToFirstField javaScript method above provides a major advantage: you are now effectively freed from having to worry about the naming hierarchy. The JQuery selector finds the field ending with a colon character followed by the specified unique fieldname. This also means you can move it around on the page and within the page element hierarchy (DOM) and not have to worry about this code failing or needing to be modified.

There’s just one more piece of code needed to ensure the standard processing doesn’t happen i.e. that the platform itself doesn’t try to be too clever and preempt what you’re trying to do. This code masks the effect of the standard “first input field positioning” processing:

	<script language="JavaScript">

	// This empty function overrides the SFDC standard function, and enables us to control initial field positioning
	function setFocusOnLoad() {


3 Comments Apex Styleguide, Part 5

Click for Part 1, Part 2, Part 3, Part 4 in this series.

Arrays or Lists?

With this post I am, strictly speaking, stepping outside of the pure topic of style. It’s one of those grey areas.

It’s that whole idea of whether to use Array or List data structures in your code. If, like me, you come from a background of programming languages where the first element of an array is element # 1, rather than element # 0, then you may also find List structures a little more intuitive because you usually don’t have to worry about element numbers when you iterate.

From the Apex language viewpoint, arrays and lists are interchangeable; you can declare a list and treat it as an array and vice-versa. Try it yourself if you don’t believe me:

public class BlogStyleGuide5 {

  // -----------------------------------------------------
  // The first method declares and populates an Array,
  // then iterates through it as a List.
  // -----------------------------------------------------
  void iterateOLI1() {

    OpportunityLineItem[] arrOLI = [
      SELECT Id, Quantity
      FROM OpportunityLineItem

    for (OpportunityLineItem iOLI : arrOLI) {
      Id      wrkId  = iOLI.Id;
      Decimal wrkQty = iOLI.Quantity;
      // Do something


  // -----------------------------------------------------
  // The second method declares and populates a List,
  // then iterates through it as an Array.
  // -----------------------------------------------------
  void iterateOLI2() {

    List<OpportunityLineItem> lstOLI = [
      SELECT Id, Quantity
      FROM OpportunityLineItem

    for (
      Integer i = 0;
      i < lstOLI.size();
    ) {
      Id      wrkId  = lstOLI[i].Id;
      Decimal wrkQty = lstOLI[i].Quantity;
      // Do something



If you were to adopt my preference for List structures rather than Arrays, you might end up having to re-code. That’s why I mentioned that this topic steps a little outside the realm of style. Therefore, please use care if you take this route. Ensure you test your changes thoroughly according to standard “good practice”.

Any comments on the above?

3 Comments Apex Styleguide, Part 4

Click here for Part 1 of this series.
Click here for Part 2 of this series.
Click here for Part 3 of this series.

This one is a little easier on the brain.

From time to time, you will come across a scenario where one structure will need to be copied to another, and there’s no option but to do it “the hard way”, as in the example below. But do you want it to look good?

// Copy temporary record to database object structure
if (copyToRecord) {
  recordObject.Name = tempObject.Name;
  recordObject.Custom_Field_String_13 = tempObject.Custom_Field_String_13
  recordObject.Address_Line_1__c = tempObject.Address_Line_1__c;
  recordObject.Address_Line_2__c = tempObject.Name;
  recordObject.City__c = tempObject.Name;
  recordObject.Country_Code__c = tempObject.Name;
  recordObject.Postcode__c = tempObject.Name;
  recordObject.Contact_1_First_Name__c = tempObject.Name;
  recordObject.Contact_1_Last_Name__c = tempObject.Name;
  recordObject.Contact_2_First_Name__c = tempObject.Name;
  recordObject.Contact_2_Last_Name__c = tempObject.Name;

Figure 1, above, shows the raw code as many people would write it. Nothing wrong with that.

// Copy temporary record to database object structure
if (copyToRecord) {
  recordObject.Name                    = tempObject.Name;
  recordObject.Custom_Field_String_13  = tempObject.Custom_Field_String_13
  recordObject.Address_Line_1__c       = tempObject.Address_Line_1__c;
  recordObject.Address_Line_2__c       = tempObject.Address_Line_2__c;
  recordObject.City__c                 = tempObject.City__c;
  recordObject.Country_Code__c         = tempObject.Country_Code__c;
  recordObject.Postcode__c             = tempObject.Postcode__c;
  recordObject.Contact_1_First_Name__c = tempObject.Contact_1_First_Name__c;
  recordObject.Contact_1_Last_Name__c  = tempObject.Contact_1_Last_Name__c;
  recordObject.Contact_2_First_Name__c = tempObject.Contact_2_First_Name__c;
  recordObject.Contact_2_Last_Name__c  = tempObject.Contact_2_Last_Name__c;

Figure 2, above, is a “cleaned-up”, column-aligned version of the same code. It took very little effort, but suddenly there’s more clarity.

OK, call me petty, but what do you want your code to say about you?