At times, it becomes necessary to carry out cleanup or summarization tasks upon the completion of a test case execution or when a test job wraps up.
Consider a requirement where you want to update an externally linked manual test case once an automation test case finishes execution. Likewise, there might be cleanup operations such as closing DB connections, etc. that should be performed either after each test case or at the conclusion of a test job.
Teardown Actions
ACCELQ's setup for teardown logic allows you to define the Actions to be executed either after each test case or at the culmination of the entire test job.
To implement this, you can script the required logic in an Action defined within the Project and then reference this Action in the Teardown settings in the Run modal.
Click on the Smart Reconcile section within the Run modal.
Under Teardown Actions, you can enable the following toggle buttons:
- Enable Teardown Action at the end of Test Case: The selected Action will execute after the completion of each Test Case in the job.
- Enable Teardown Action at the end of Test Job: The chosen Action will run once the entire Test Job concludes.
It's important to note that the Action designated to run at the conclusion of each Test Case will also execute at the end of the Test Job, forming part of the final test case in the Test Job's sequence.
Teardown Actions are triggered regardless of how a test case or test job concludes. This includes situations where the test case was completed with an error or was aborted logically; the teardown Actions will activate at the conclusion of the test case or test job.
However, if the test job is aborted manually from the Results page, then the teardown Actions do not get triggered.
Parameters in Teardown Actions
If the Actions assigned for Teardown involve any input parameters, you will provide these values when initiating the test. These values are cached, and auto-populated in the subsequent runs.
Important Note about Teardown Actions
Teardown Actions are intended to facilitate the execution of standard, routine logic applicable across various Scenarios and test cases. The logic and parameterization used in these Actions must remain universally applicable, not tailored to any individual Scenario or test case.
If you find a need to incorporate logic/parameters specific to a Scenario or test case, it is appropriate to include such logic as a standard step in the required Scenario.
Other Remarks
-
Any failure in the teardown Action results in marking the test case as failed.
-
During parallel execution, the Test Job teardown runs in the thread that manages the final test case in the job's sequence.
-
When change management is enabled (Version control), teardown executes only the base version of the Action. Changes made in the checked-out state of an Action are not utilized.
-
Teardown Actions are never invoked recursively. If there is an abort statement within a teardown Action's logic, the test job or test case simply completes without further action.
Notes on Logic Development
Enabling Teardown only on test case failure
In case you have a requirement to run Test Case Teardown Action logic conditionally only when a Test Case fails, you may insert a conditional statement in the Action logic marked for the Test Case Teardown.
Use the command: Is current test case failed. As shown in the image below, open the Action you marked as Teardown Action, and place these statements on the top of the logic. You are instructing the teardown Action to exit in case the test status is NOT a failure. (notice the "False" in comparison)
Similarly, you can put several other conditional statements in the Teardown logic to achieve various objectives.
Building Logic in Teardown Actions
Creating Teardown Actions follows the same principles as any standard Action, without any specific limitations. However, when constructing teardown logic, you may frequently encounter the necessity to gather information about the current test job and the test case currently in execution.
This article provides a listing of such useful commands.
Best Practices for Teardown Actions
✅ Recommended in Teardown:
-
Closing database connections or file handles.
-
Deleting test data created during the test run (e.g., removing user accounts via API).
-
Logging results or updating external test management systems.
-
Resetting or restoring environment configurations modified during tests.
-
Aggregating and sending test summary reports or logs to external systems.
🚫 Avoid in Teardown:
-
UI-level cleanup (e.g., clicking logout buttons or closing browsers manually).
-
Platform-specific teardown (mobile app closure, UI navigation cleanup).
-
Scenario-specific logic (only applies to one specific use case — better placed inside the scenario).
-
Waiting for or interacting with UI components (Teardown should not rely on active UI states).
🔥 Pro Tip: Treat teardown logic like a “background worker” — invisible to the user, universal in behavior, and focused on environment integrity, not test flow control.
✅ Teardown Action Use Case Examples
Requirement | Job-Level Teardown | Test Case-Level Teardown |
---|---|---|
Sending test summary to a Slack channel or dashboard | ✅ | 🚫 |
Deleting temp records created during a test case | 🚫 | ✅ |
Cleaning up test artifacts (files, logs, API records) | ✅ | ✅ |
Closing reusable DB or API connections | ✅ | 🚫 |
Platform-specific cleanup (e.g., closing browser, app logout) | 🚫 (place in scenario step) | 🚫 |
Comments
0 comments
Article is closed for comments.