Logging into your app

Many testing scenarios require logging into an application before validating its functionality. In mabl, you can automate logins by recording steps in the Trainer. When these tests run in the cloud, they always start with a fresh instance. This means that every test that validates a logged-in interaction has to authenticate independently because session data, such as cookies or cache, don’t persist to subsequent runs in the same plan.

In mabl, you can use flows to simplify this process: train the login for your app once and reuse it across other tests that require the same type of login. Login flows help you add test coverage faster and reduce the need to maintain login steps separately for every test.

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

• Use test credentials
• Identify an approach for credentials
• Establish naming conventions
• Limitations to automating logins

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

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 with mabl credentials for the following reasons:

• Workspace owners can assign user roles to manage access to mabl credentials, including the ability to restrict access to specific users with resource groups.
• 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.

Environment-specific credentials

mabl does not support assigning environment-specific credentials. If a plan requires different login credentials to run in different environments, consider substituting mabl credentials with environment variables as a workaround. The drawback of this approach is that you cannot currently use resource groups to restrict access to environment variables.

If this limitation impacts your workflow, please let us know in the mabl Product Portal.

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 logins

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

• reCAPTCHA or CAPTCHA
• 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