Functionality of some elements in the layout can be covered by unit tests. For example, in custom apex or visual force controllers.

However, those functions work independent from the layouts. Unit tests there should still pass, even after the related elements have been removed from the layout.

There doesn't seem to be any built-in solution to test the layout itself - to confirm that the element is still displayed on the page, and hasn't been inadvertently removed from the layout.

This can be tested using a 3rd party tool like Selenium. Is that a common practice? Will it add value?

2 Answers 2


Is that a common practice?

No, it's not, at least based on my experience. Besides the layout, you'd also have to check security, etc, etc. To make matters worse, unit tests don't run when you edit a layout, so you wouldn't know anything is wrong until after it was too late to fix things. Also, this could be a lot of overhead in terms of maintenance if you have a lot of layouts to manage.

Will it add value?

Not likely. Admins and developers alike should be following deployment processes, preferably using Git or some mechanism to easily rollback bad deployments/track changes/etc. If you're in the habit of using source control, a simple diff can tell you if anything is amiss. It's not really so much a "test" as it is a sanity check.

That said, if you wanted to verify specific elements, you can, and you don't need Selenium to do so. Thanks to the Metadata namespace, you can now query your layouts in a unit test, which you could run as part of your deployments or periodically.

Here's some code to get you started:

@istest public class TestLayoutConfigs {
    @istest static void test() {
        Metadata.Metadata[] components = Metadata.operations.retrieve(Metadata.MetadataType.Layout,new String[] { 'Account-Account Layout' });
        System.assertEquals(1, components.size());
        for(Metadata.Metadata component: components) {
            Metadata.Layout layout = (Metadata.Layout)component;
            // Do something for each layout

See the Metadata class and its related methods in the documentation for more details.

  • Thanks for weighing in. I don't think I can accept the answer as-is. The part about the Git diff doesn't jibe with my experience with automation in general. Any otherwise-manual procedure that is repeated on a regular basis, even a sanity check, is worth automating. However the code you shared is exactly what I was looking for. Selenium would definitely be overkill in this case. Aug 21, 2017 at 20:47
  • @PatMeeker Salesforce wants us to move to source-driven development (e.g. Salesforce DX. Take it or leave it, but I feel that simply verifying metadata would be far more efficient than writing unit tests. Unit testing is to verify logic, and there's no "logic" in a field. Verifying that your metadata is correct should be a simple diff, and to test your code, you use unit tests.
    – sfdcfox
    Aug 21, 2017 at 21:07

We have used Selenium in our project and it has worked wonders for our page layout testing. Being able to automate this enabled our fast delivery time even when the business users modified the page layout on their own With lightning though SF has taken away namespace and unique in de and now all our selenium tests are invalid and there’s no point in updating them as Sales Force can change the relative XPath of the Page elements anytime they like Extremely disappointed It feels SF deliberately discouraged any kind of standard CICD practices and for that matter good coding practices

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .