Test execution cleanup logic with Teardown Actions

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.

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