In automated testing, preparing the right test environment before executing your scenarios is just as critical as validating the outcomes. ACCELQ’s Setup Actions feature allows you to define reusable initialization logic that runs automatically at the beginning of a test case or test job. This helps establish a consistent baseline for your executions and simplifies the management of common preconditions.
What are Setup Actions?
ACCELQ enables you to define logic that executes automatically:
-
Before each Test Case: Useful for establishing conditions that need to be reset between tests.
-
At the beginning of a Test Job: Useful for setting up context shared across all tests in the job.
These Setup Actions are defined as regular ACCELQ Actions and then associated with your test execution via the Run modal settings.
How to Configure Setup Actions
To configure Setup Actions:
-
Create an Action that encapsulates the setup logic.
-
Navigate to the Run modal when launching a test job.
-
Under the Smart Reconcile section, configure the following:
-
✅ Enable Setup Action at the beginning of each Test Case
-
✅ Enable Setup Action at the beginning of the Test Job
-
You can configure one or both, depending on your needs.
📝 Note: If both are enabled, the Test Job Setup Action will run once before the first test case, and the Test Case Setup Action will run before each test case in the job.
Passing Parameters to Setup Actions
If your Setup Action requires input parameters:
-
You can provide values during the job kick-off. You may either supply literal values, or Global Properties for parameter values.
-
ACCELQ caches the last-used parameter values to simplify future runs.
Execution Behavior & Key Considerations
-
Global in Scope: Setup Actions should include logic that is universally applicable across all or most test cases.
-
Execution Assurance: These actions always run before a test case or job, regardless of any previous test case outcomes.
-
Failure Impact: If a Setup Action fails, the associated test case (or entire job for job-level Setup) is marked as failed.
-
Version Control: In environments with Change Management enabled, only the base version of the Setup Action is used during execution. Changes made in a checked-out version will not be executed.
- Effect of "Abort" statement during Job Setup: The entire job is terminated if the logic in your Setup Action invokes Abort command for "job". There is no effect of an Abort command with "testcase" option.
- Effect of "Abort" statement during Test Case Setup: The entire job is terminated if the logic in your Setup Action invokes Abort command for "job". Whereas, the current test case is aborted if the Abort command with "testcase" option is triggered in your logic.
Behavior under Parallel Execution
When running with parallel threads, the Test Job Setup only runs for the first test case amongst all the parallel threads. Until the logic in the Setup Action is executed, other threads are blocked from picking up test cases.
Behavior under Distributed Jobs
Currently, Test Job Setup runs individually for each sub-job created on different Agents in a distributed Agent execution.
Conditional Execution in Setup Actions
ACCELQ provides a library of commands to control execution flow of Setup Actions by being able to parse the test run status in the Action logic. Refer to this article for available commands.
This is helpful in situations where you want to run Setup Action logic based on test case status, or other parameters.
Best Practices for Setup Actions
✅ Do include:
-
Test data initialization (e.g., creating mock accounts, populating APIs with base data).
-
Resetting shared state or cleaning remnants from previous runs.
-
Environment setup logic that applies across multiple types of tests (API, UI, Mobile, etc.).
-
Authentication tokens or test context preparation, if applicable to all scenarios.
🚫 Avoid including:
-
Browser or mobile app launch logic: Since ACCELQ supports diverse automation (web, mobile, API, middleware, etc.), platform-specific setup should live inside the Scenario steps, not the Setup Action.
-
Scenario-specific configurations or validations.
-
Long-running or complex logic that could significantly delay the start of each test case.
When to Use Test Job vs. Test Case Setup Actions
Requirement |
Job-Level Setup |
Test Case-Level Setup |
---|---|---|
Generating an API token for service access (no UI involved) | ✅ | 🚫 |
Resetting or inserting mock test data into a database or middleware | 🚫 | ✅ |
Creating baseline test data via API (e.g., customer record) | ✅ | 🚫 |
Initializing environment-wide config (e.g., setting headers, system flags) | ✅ | 🚫 |
Launching a browser or mobile app | 🚫 (belongs in scenario step) | 🚫 |
Logging into a web/mobile app | 🚫 (belongs in scenario step) | 🚫 |
Bonus Ideas – More Common Automation Setup Use Cases
Here are a few more real-world examples that are great fits for Setup Actions (or important to avoid):
✅ Good candidates for Setup Actions:
-
Setting up a mock server or stubbing services for test isolation.
-
Reading and loading test configuration from an external file.
-
Setting feature flags or toggles for enabling/disabling functionality during test runs.
-
Performing a health check on a downstream service (API ping, DB availability).
-
Registering a dynamic test environment ID before execution.
🚫 Avoid putting in Setup Actions:
-
Selecting UI elements or navigating menus.
-
Interacting with third-party tools that only run inside a browser/mobile app (e.g., CAPTCHA).
-
Clicking buttons or filling out forms.
-
Waiting for UI elements to be visible or clickable.
Teardown Action vs. Setup Action
ACCELQ supports both Setup Actions and Teardown Actions to manage logic that runs before and after your tests. Setup Actions help prepare the environment, while Teardown Actions are used for cleanup after test execution.
Sometimes, cleanup may be needed at the start of a test—for example, clearing old entries from a database table before inserting new test data. In such cases, this can be part of a Setup Action, as it's preparing the environment for the test.
However, if the cleanup is meant to remove or revert changes made during the test—like deleting test data inserted during execution—it should be placed in a Teardown Action to ensure the environment remains consistent for future runs.
Learn more about Teardown Actions
Comments
0 comments
Please sign in to leave a comment.