0% Complete

Introduction

Before taking this lesson

Make sure you are comfortable with the following lessons:

  • Understand how to navigate the mabl Workspace
  • Know how to create Plans and Tests in mabl

Learning Objectives 🧠

By the end of this you will:

  • Understand how and where you can trigger tests in mabl
  • Be able to schedule tests or run them ad hoc
  • Know why these different options are valuable

Why is this important?

Vital to automation, maintenance & Pipeline

  • Automated runs allows constant monitoring of apps without manual intervention
  • For test maintenance, running ad hoc tests makes it easy to validate new tests, or edits you’ve just made, even without leaving the Trainer. 
  • In more advanced courses, we will show you how to trigger tests via API as you integrate mabl into your CI/CD pipeline  

What is it?

How to run tests

  • Triggers initiate the execution of the test, either in the cloud or locally on your machine.
  • Scheduled/Triggered Cloud runs will take advanced of mabl's Execution Engine (auto-heal, screenshots, insights, etc...)
  • Ad-hoc test runs are intended to provide a way to validate test edits without impacting overall stats, metrics, and insights. They will run using the same execution environment and strategies as Scheduled/Triggered Cloud runs, but any auto-heals will not be saved.

How do I use it?

Test triggers can be found in multiple places:

  • Plans Details Page
  • Plans Page
  • Tests Details Page (Ad-hoc runs)
  • Trainer
  • mabl CLI (advanced)
  • API (advanced)
  • CI/CD Integrations (advanced)

Plans

Cloud runs can be triggered or scheduled at the Plan level, either on the Plans Page:

 

In the Plan Details Page:

Or set when creating/editing a Plan, which allows the User to select either by Deployment (via API or CI/CD), by scheduling the test to run on certain days of the week and at certain times (these options can be stacked, as shown in the video, so you can select Monday at 4:00AM and Wednesday at 1:00AM) or on a timer:

 

Scheduling Plans for certain days of the week allows you to run tests when you know your team will not be using the environment, enabling you to better manage your resources

  • NOTE: The time you select is the user’s local time. 
  • NOTE: The users need to make sure both the Plan and Tests within the Plan are enabled, otherwise neither will run
    • Using the “Timer” option is a great way to set up smoke tests that need to run every several hours - this is for vital features that need to be up and running all the time.  mabl’s Timer allows you to run Tests as frequently as every 15 minutes.

Tests

Triggering Ad-hoc runs can be done either from the Test Details Page or in the Trainer.  Please bear in mind that ad-hoc test runs are intended to provide a way to validate test edits without impacting overall stats, metrics, and insights - this means auto-heal will not impact any passing runs.

Triggering an Ad-hoc run from the page of the Test provides more options for how you’d like it to run:

  • Local Run Options (will use the standalone app to run a test on your local machine):
    • Run Headlessly (the browser UI will not be shown)
    • Keep browser open (browser will remain open after test completes, for easy inspection)
    • Select the environment(s)
    • URL override
    • Select Login and/or HTTP basic auth credentials
  • Cloud run Options (will execute remotely inside the mabl cloud):
    • Desktop or Mobile Web [beta] 
    • Select browser(s)
    • Select environment(s)
    • URL override
    • Select Login and/or HTTP basic auth credentials
    • Run DataTable scenario(s)
    • Cloud run (will execute remotely inside the mabl cloud)

Trainer

Running tests from the Trainer enables you to get quick feedback on new or changed tests, ensuring your tests are working as expected without contributing toward your cloud run allotment. Here is how you can incorporate local runs into your workflow:

  • Create a new test or edit an existing one
  • Save the test
  • Run the test locally (either from the Trainer or the test details page) to ensure that the test is passing locally
  • Run the test in the cloud on one or more devices and browsers to ensure that the test is passing in the cloud

 

Recap

Reflect

What did we learn?

  • Why triggering tests is important
  • How and where to trigger/automate tests in mabl
  • Understand the differences between trigger options

Connect

  • How is it related to what you know and are doing?
  • More text about how it connects

Apply

  • How to use this going forward?
  • More text about how it applies

Feedback

Was this helpful?

Take this 2 minute survey to let us know how we can make mablU better!