Logging into your app

Best practices for logging into your app in mabl browser tests

Many testing scenarios require logging into an application before validating the target feature. You can train your browser tests to log into your app by recording steps in the mabl Trainer.

To simplify this process and reduce the need to create and maintain login steps for each test, you may convert these steps into flows and import them into other tests that require the same type of login.

A login flow incorporates credentials - username and password - into a parcel of reusable steps that you can apply as needed to your mabl browser tests.


Example of a login flow in the mabl Trainer


Assert on login

As a best practice, add an assertion step after logging in to confirm that the login was successful.

This guide outlines best practices for creating and managing login flows in your mabl tests:

  • Use test credentials
  • Identify an approach for credentials
  • Establish naming conventions

Use test credentials

Mabl stores your data securely, encrypting credentials with a workspace-specific encryption key. To further ensure that your applications are secure, we recommend the following:

  • Create test credentials in your application to use for your mabl tests
  • Avoid using credentials that reveal personally identifiable information in your mabl tests
  • Use cloud credentials for test environments that access sensitive data.

Keep in mind that output from tests that use basic credentials is stored in your mabl workspace, where your other team members can view results. This output includes:

  • Screenshots
  • Chrome traces
  • HAR logs

Identify an approach for credentials

The primary way to log into your application is with mabl credentials. Mabl credentials are a special class of variables that are configured at the workspace level and passed in at run time.

We recommend creating login flows that use mabl credentials for the following reasons:

  • Workspace owners manage access to mabl credentials with user roles.
  • Mabl credentials are not readily visible in your flows and tests.
  • Mabl credentials have an extra layer of encryption within mabl.
  • You can save mabl credentials as cloud credentials for extra security.

For more information on setting up mabl credentials for your tests, check out the mabl credentials guide.


Support for MFA logins

If your application uses multi factor authentication, see our guide on support for MFA logins.

Alternative approaches to credentials

Mabl credentials have two limitations:

  1. You cannot configure mabl credentials per environment.
  2. Plans can only use one set of mabl credentials.

In the event that a plan requires different credentials per environment or multiple sets of credentials, you may consider one of the alternative approaches outlined in the following table:



Environment variables: add credentials as environment variables and use in tests that run in multiple environments

  • Any member of the workspace can see the values in the test output.

Designated login flows: create login flows with hard-coded credentials for specific roles and use in tests as needed.

  • Any member of the workspace can see the values in the test output.
  • You cannot update these credential values outside of the mabl Trainer.

DataTables: to run a test multiple times with a different set of credentials each time, associate the test with a DataTable that has a scenario for each set of credentials. The test runs once for each credential scenario in the DataTable.

  • Any member of the workspace can see the values in the test output.
  • If you need to access additional DataTable variables in a test run besides credentials, you need to add those variables to the same DataTable that contains the credentials.
  • Running all DataTable scenarios in local runs is not supported.

Establish naming conventions for login flows

Establishing a naming convention for login flows makes it easier for other members of your team to reuse flows and helps you avoid doubling your efforts.

Helpful pieces of information may include user role and the application. For example:

  • User login - main app
  • Admin login
  • Employee login - HR portal

Limitations to automating login

Mabl does not support automating login for apps that use the following anti-automation countermeasures:

  • NTLM

Anti-automation countermeasures are commonly used by social identity providers, such as Google, Apple, Facebook, LinkedIn, and GitHub. When testing applications that use social identity providers, consider using an alternative means to expose login to the application, such as one of the following:

  • Using username/password login instead
  • Exposing special login tooling in your testing environments for automation users
  • Using provider supplied tooling for testing automation, such as Service Accounts + Google IAP


The mabl Trainer does not support automating logins to Google.