Showing posts with label software development. Show all posts
Showing posts with label software development. Show all posts

Monday, 19 January 2026

Run Relevant Tests Annotations in Spring '26

Image created by ChatGPT5.2 based on a prompt by Bob Buzzard

Introduction


In my first post on this new functionality I did a bit of digging into which tests are chosen when code is changed. If leaving it up to Salesforce doesn't quite cut it, there's the option to influence things via the two new parameters for the @isTest annotation. 

As in the first post, I've got a small set of classes with dependencies that are sometimes static and sometimes dynamic. As a refresher the key classes are:
  • OpportunityUtils
    The protagonist in my little drama is a class named  This implements an interface (OpportunityUtilsIF) with a single method, getBigDeals(), which receives a collection of opportunities and returns a new collection containing just those opportunities with a value greater than or equal to 250,000.

    There is a dedicated test class (OpportunityUtilsTest) which directly instantiates the class and executes a zero/one test. 
  • OpportunityEOD
    This contains a single method (EODProcessing) that extracts all opportunities created today, creates an instance of OpportunityUtils, extracts just the big deals, appends ' - BIG DEAL' to their name and updates them.

    There is a dedicated test class (OpportunityEODTest) that inserts test opportunities of varying values, instantiates OpportunityEOD and executes the EODProcessing method, then extracts all opportunities from the database that are greater than or equal to 250,000 and asserts each name contains ' - BIG DEAL'.

  • OpportunityWrapLevel1
    This contains a single method (EODProcessingWrapLevel1) that instantiates the OpportunityEOD class and executes the EODProcessing method.

    There is a dedicated test class (OpportunityWrapLevel1Test) that inserts test opportunities of varying levels, instantiates OpportunityEODWrapLevel1, executes the EODProcessingWrapLevel1 method, then extracts all opportunities from the database that are greater than or equal to 250,000 and asserts each name contains ' - BIG DEAL'.

  • OpportunityEODInjection
    This  contains a replica of the EODProcessing() method, but rather than directly instantiating OpportunityUtils it is passed a parameter (implementing the OpportunityUtilsIF interface. There is a dedicated test class (OpportunityEODInjectionTest) that delegates to a test factory to dynamically create an instance of OpportunityUtils based on the class name - at no point is OpportunityUtils directly referred to. The test mirrors the other EOD tests, inserting opportunities, carrying out the EOD processing and verifying that ' - BIG DEAL' is appended where appropriate.

As we are now in the scratch org preview window, I was able to use my pre-release developer edition as a Dev Hub and create a Spring '26 scratch org, which speeds things up enormously and lets me scrap everything and start again from scratch with minimum effort.

@IsTest(critical=true)


This parameter tells the Salesforce test engine that the tests in this class must execute when a deployment takes place. I originally misread the docs on this and thought the test only executed if the payload contained Apex changes, but that isn't the case. Setting a test class as critical means it always executes for a deployment that runs relevant tests regardless of what is being deployed. To confirm this, I returned to the classic example of a configuration change that breaks tests with ease - the validation rule!

I marked my OpportunityEODTest class as critical, attempted to deploy an Opportunity validation rule that required one of Description or Lead Source to be populated, and duly watched the test execute and the deployment fail! 

This is a great addition, as the critical tests are identified without the deployer having to remember which tests they should always run. That said the deployer does still have to remember to deploy with the RunRelevantTests option, so it's not a silver bullet.

@IsTest(testFor='<classes_and_triggers>')


This parameter comes in handy if the Salesforce test engine isn't picking up all the tests that matter. In my first post I explained how it isn't really reasonable to expect the test engine to pick up dynamic instantiation of the OpportunityUtils class based on its name, which is how it's used in OpportunityEODInjection. Using the testFor parameter I can give the test engine the helping hand it needs:
    @isTest(testFor='ApexClass:OpportunityUtils')
    private class OpportunityEODInjectionTest {
        @isTest
        static void TestEODProcessing() {
           ...
        }
    }
  
Note that I don't have to include OpportunityEODInjection in the list of classes identified in the testFor parameter. I'm adding to the tests that are executed, not overriding them. This test is also executed if I change the OpportunityEODInjection class, as it has a direct dependency on it which the Salesforce test engine can pick up.

Even though that is the case, I think in a real-world environment I'd prefer to list all the classes/triggers that the test class is associated with, as it improves clarity and saves a developer having to figure things out manually, even if there is overhead to create and maintain this information. 

More Information


Follow on LinkedIn



Friday, 25 April 2025

Evaluate Dynamic Formulas in Apex in Summer '25


Image generated by ChatGPT o3 in response to a prompt by Bob Buzzard
Proving yet again AI isn't good at putting text in images!

Introduction

The ability to evaluate dynamic formulas in Apex, which went GA in the Spring '25 Salesforce release, gets a minor but very useful improvement in the Summer '25 release - template mode. In this mode you can use merge syntax to refer to record fields, making formulas that concatenate strings much easier to specify.  Using the example from the release notes,  rather than writing the formula to combine an account name and website as a clunky concatenation :

    name & " (" & website & ")"

we can write:

    {!name} ({!website})

and tell the formula builder to evaluate it as a template. This felt like a good addition to my formula tester page, that I created to demonstrate the Spring '25 functionality, and it also uncovered some unexpected behaviour.

The Sample

My formula tester page is updated to allow the user to specify whether the formula should be evaluated as a template or not via a simple checkbox under the text area to input the formula:


I've also tried to make the page helpful and added an onchange handler to the text area that toggles the Formula is template checkbox based on whether the entered text contains the patter {! - note that the user can override this if they need that string literal for some other reason:



Note also that there's a timeout of 1 second in the onchange handler so it will only fire when the user has (hopefully) finished typing. 

There will be code


The revised Apex method to build and evaluate the formula is as follows:

@AuraEnabled
public static String CheckFormula(String formulaStr, String sobjectType, String returnTypeStr,
                                  Id recordId, Boolean formulaIsTemplate)
{
    FormulaEval.FormulaReturnType returnType = 
                   FormulaEval.FormulaReturnType.valueof(returnTypeStr);

    FormulaEval.FormulaInstance formulaInstance = Formula.builder()
                                    .withType(Type.forName(sobjectType))
                                    .withReturnType(returnType)
                                    .withFormula(formulaStr)
                                    .parseAsTemplate(formulaIsTemplate)
                                    .build();


    //Use the list of field names returned by the getReferenced method to generate dynamic soql
    Set<String> fieldNames = formulaInstance.getReferencedFields();
    Set<String> lcFieldNames=new Set<String>();
    for (String fieldName : fieldNames)
    {
        lcFieldNames.add(fieldName.toLowerCase());
    }
    if (lcFieldNames.isEmpty())
    {
        lcFieldNames.add('id');
    }

    String fieldNameList = String.join(lcFieldNames,',');
    String queryStr = 'select ' + fieldNameList + ' from ' + sobjectType + 
                      ' where id=:recordId LIMIT 1'; //select name, website from Account
    SObject s = Database.query(queryStr);
    Object formulaResult=formulaInstance.evaluate(s);
    system.debug(formulaResult);

    return formulaResult.toString();
}
The bit I expected to change was the additional formulaIsTemplate parameter and invoking parseAsTemplate on the builder. While testing however, I found that if I built a string literal without using any fields, my fieldNameList parameter was empty and I got an error running the SOQL query of select from Account where id='<blah>'.

My first attempt at a fix was to skip the query if the field list was empty, but the evaluate method errors when passed a null sObject parameter. No problem, I'll just add the Id field if the Set of field names is empty. 

Turns out there was a problem. I checked if the field named Id was in the Set, which it wasn't, then added it. Executing the query duly errored as I had a duplicate field in my query. It turns out that the getReferencedFields method isn't case agnostic and it considers Id as a different field to id and returns them both in the Set.

To confirm this I ran the following Apex:

FormulaEval.FormulaInstance formulaInstance = Formula.builder()
		.withType(Schema.Account.class)
		.withReturnType(FormulaEval.FormulaReturnType.STRING)
		.withFormula('{!name} {!Name} {!NaMe} {!NAME}')
		.parseAsTemplate(true)
		.build();
        
String fieldNameList = String.join(formulaInstance.getReferencedFields(),',');
System.debug('Field name list = ' + fieldNameList);
and got the output:

    09:55:32:043 USER_DEBUG [9]|DEBUG|Field name list = NAME,NaMe,Name,name

So I had to add some extra code to iterate the field names, lower case them and add them to a new Set to remove any duplicates. Then I could check if it was empty and if it was add the id field.

You can find the updated code in my Summer 25 samples repository - note that this needs a Salesforce instance on the Summer '25 which, at the time of writing (April 25th), is pre-release orgs. Sandboxes are available on May 9th and scratch orgs on May 11th, assuming Salesforce hit their dates.

More Information





Saturday, 21 August 2021

The Public Nature of Modern Programming

Then

When I got my first programming job, way back in 1987, it was a quite a private and solitary occupation. The Design Authority for my project gave me a detailed design for a procedure, including explicit definitions of the interfaces that I would use to interact with the rest of the system. I would then write the code for the procedure, test it locally and check it into version control. If I didn't need any clarification, I wouldn't speak to anyone as part of this process. I'd chat to my colleagues that I shared an office with, but in terms of doing my work it would be me and a screen. 

My code wouldn't be looked at by anyone else unless there was an issue when the next build took place, which there always was, as there were hundreds of new procedures that had never been slammed together before. The build team would take the first stab at fixing the issues, and if they were successful then I wouldn't know anything about this. If they were unsuccessful we would then enter a period of confusion as they typically wanted help with their fix rather than the underlying problem, and I would wonder where this code they were talking about had come from. 

My working life was spent solving problems that others were probably spending time solving, but it would never have occurred to me to share information about what I was doing, nor would I have had the first clue about how to go about sharing it. 

Outside of work, I would almost never talk to anyone about programming unless I was catching up with someone I'd been at college with, but it would be very superficial and typically about which languages and business areas we were working in, before getting down to the serious business of talking about sport. I'd also rarely do any programming outside of work. I might fiddle around a bit with some Basic, Pascal or 6502 assembler on my BBC Model B, but nothing serious. And certainly nothing that I'd consider telling anyone else about.  Some people wrote games and sent the source into magazines that might print it, but as a professional programmer I already got paid to write code so didn't need this outlet. 

Programming was a job like any other - I went to an office, worked there for a set number of hours a day, then went home and did whatever else I was interested in at the time. Unless you were a close friend or family member, you wouldn't have known that I programmed computers for a living, and unless you were a programmer yourself, it was hard for me to communicate exactly what I did every day.

The stereotype of a programmer was someone sitting in a darkened basement, being fed written requirements, and spending their days staring at a screen and typing. Which was pretty accurate.

Now

Programming in 2021 has changed beyond all recognition. It's now a collaborative and very public occupation. Requirements are rarely written down, and if they are it is often the programmers doing that after speaking to "the business" to find out exactly what is needed. Outside of integrating with external systems, integrating with the rest of the code in the project involves collaboration with the other programmers and the interfaces change when it becomes apparent they need to. Code is reviewed before being added to version control and continuous integration flags up problems as soon as they occur. The idea that a team of humans would need to kick off a build and triage the problems seems quaint and incredibly inefficient now. 

For me, the biggest change is that programmers expect, and are expected, to have a public profile. 

When we solve a problem, we write a blog post about it, redacting any detail that might expose which customer this impacted. We cross post on Substack and Medium. There might be a Github repository with the sample code for the blog post - there will almost certainly be other Github repositories to showcase our work, sometimes complete applications that anyone is welcome to copy. 

We also perform for audiences now, as we share what we've been doing at meet ups, conferences (both community and vendor organised), podcasts, webinars and recorded sessions. I'm pretty sure for the first 5-10 years of my career I didn't even show a customer what I'd built for them, it just got rolled into demos and training carried out by others. Now I show complete strangers from around the world and it seems perfectly normal.

Which is Better?

From the point of view of solving problems and producing solutions, it's almost unrecognisable now. If you hit a problem with anything other than bleeding edge technology, it's incredibly likely that someone else has already hit it and fixed it. And blogged about the fix. And spoken at a conference about it. And maybe created a Github repository with all the code you could possibly need going forward. 

The flip side is that programming is now more of a lifestyle choice than a job. There is an expectation that you will be working on side projects, writing posts and presenting at conferences. Often this will be on top of your actual job, which means that your social life is merely an extension of your professional life and often indistinguishable. Going to the office and working a set number of hours is typically only part of the programmer life these days, which can bring a lot of pressure, especially if you don't see it as a calling.  It can also be a full time job keeping up with the latest developments - frameworks rise and fall, platforms come in and out of favour, or the baddies get a new CEO and become the goodies so you grudgingly have to skill up on their products.

Personally I find it a lot better now that it was when I started, but very I'm lucky in that (a) I enjoy what I do, and (b) I can dedicate large chunks of my own time to all the extra-curricular activities without making my personal life difficult. I'm sure nobody wants to go back to the days when the helpful information was silo'd or didn't exist, but I'd imagine there are some out there who would quite like a return to the days when programming was something you did in private.