Automated Testing

Automated testing is the process of writing scripts of actions, and their expected results, to be run within a browser by a computer. These scripts, or tests, are used to verify that the various parts of an application function as intended. The success or failure of those scripts determines whether or not an application is in working order.

These tests can be executed on an individual developer’s local machine while building an application, or run automatically as a part of a CI/CD workflow when a developer’s source code is pushed to a repository. All of this typically occurs before user acceptance testing (UAT)—where human end users actually utilize an application for its intended purpose.

Like other software applications, the pages of Skuid apps can also be tested to ensure that they are functioning as intended, even as Skuid admins make changes to pages. These automated tests can then alert the organization when a particular change breaks a part of page, perhaps preventing a component from rendering or a model from querying and returning data.

While the landscape of testing frameworks is vast, there are some consistent processes and best practices to keep in mind when designing tests for Skuid.

Note

  • The examples discussed below assume you are working with a Skuid NLX site. Many of these same concepts can be applied to Skuid SFX deployments as well, though their implementation will vary.
  • The sample code below is in JavaScript, but you may use your language of choice per your testing suite.

Prerequisites and Concepts

While the examples included here are basic and written to be understood by most builders, knowledge of automated testing concepts and terms is recommended before proceeding.

Some important concepts include:

  • Test-driven development (TDD)
  • Behavior-Driven Development (BDD)
  • Familiarity with the command line
  • How to install testing frameworks and any of their dependencies
  • How automation software interacts with page elements, i.e. how to target page elements via CSS selectors.
  • If using a JavaScript/Node.js-based framework:
    • Due to JavaScript’s asynchronous nature, ensure you are familiar with async/await syntax for writing proper test scripts.

Overview of Automated Tests for Skuid

Regardless of testing framework, you must write tests that do the following:

  1. Log in to a Skuid site or Salesforce environment.
    • When working on Skuid NLX, login credentials are typically sourced from environment variables.
    • If working with a Skuid SFX implementation, consider using the force CLI to automate the login process.
  2. Open a page to test.
  3. Target specific elements on the screen to test an expected behavior.

After writing these scripts, run the tests—manually or through a CI/CD system.

The results of the tests can be output to a file on your local machine or, if applicable, processed by a separate CI/CD process to update records within other connected services—such as a test case management integration.

Writing Automated Tests for Skuid

  • Write tests in the programming language of choice, using specific element selectors for your Skuid page components.
    • When building Skuid pages, make extensive use of the unique ID property on components.
  • If you are less experienced in writing code, or are not sure how to begin using element selectors, consider using Selenium IDE. This tool can record interactions to draft automated tests, and then run them, without handwriting tests from scratch.
  • In the design stage for the application—potentially before using any Skuid components—identify definitive, repeatable behaviors. Keep tests small and well defined. For more complex behaviors, set up a series of tests so you can tell exactly where the page logic encounters issues.
  • (Optional) If moving Skuid pages to a specific testing environment before running automated testing, use the skuid-sfdx Salesforce CLI plugin to quickly move pages from one environment to another.

Best Practices for Designing Tests

  1. Create and document test scenarios before attempting any automation.
  2. Identify test candidates suitable for automation. For example:
    • How often does the test need to be repeated?
    • How difficult is it to automate?
  3. Choose an automation tool that is best for your needs.
    • For example: Do you have the resources to code tests? Which coding language?
    • Would it be better to use a record and playback tool, like Selenium IDE?
  4. Make full use of the Unique ID property within components.
    • These unique IDs propagate to Skuid’s runtime DOM as the id HTML attribute. These are the best and most flexible element locators when automating.
  5. Break up automated tests into logical groups.
    • A smaller “Smoke Test” suite that can be run quickly on changes.
    • A larger “Full Test” suite to run before deploying to production.
  6. Use a known subset of test data or fixtures for automated tests, if possible.
    • Tests run faster and are more stable with a smaller subset of data as opposed to full datasets or production data analogues.