How to skip a test teardown?

Robot Framework
1

Hello everyone,

I am wondering whether there is a way to skip the execution of a test teardown when the test case is intentionally Failed or Skipped.
I am totally fine with executing the Suite teardown when all remaining test cases are Skipped but I am missing the point of executing a teardown of a test case which was Skipped or cancelled intentionally.

There are keywords for “…if test failed/passed” but none for “if test (was) skipped”. I am sure we can write these keywords on our own as a part of some resource file, but a more supported way would be welcome :slight_smile:

Thank you
David

2

Hi @Oavio

You can make use of an Automatic variables: ${TEST STATUS} within the test teardown as its available for usage with the test teardown and do a conditional check if it’s not equal, or simply just check if status is PASS or FAIL

But from just having a play if you are using “[Tags] robot:skip” which is classed as " Skipping before execution" then it won’t step into the teardown, but if you call SKIP keyword instead then the teardown is executed still, please see this line if skipping dynamically during execution:

  • Using the BuiltIn keyword Skip anywhere in the test case, including setup or teardown. Using Skip keyword has two effects: the test gets the SKIP status and the rest of the test is not executed. However, if the test has a teardown, it will be run.

Hope that helps and gives a possible workaround if doing dynamically, it’s defiantly worth casting over the robot framework documentation if you have time as it has some really good information :slight_smile:

Thanks

1 Like
3

Hey daryl,

Thank you for your response.

Our case is the dynamic skipping, and I am aware of the Skip keyword description in documentation.
I just don’t get why the Teardown is automatically triggered after the test case is skipped using that keyword. It would make sense to me if the triggering of the Teardown was configurable via an optional argument for Skip keyword.

We already use the conditional check on ${TEST STATUS} but it makes our Teardowns more messy…I guess it the only way for now :pensive:

Thanks again
David

1 Like
4

No problem David, yeah it does seem that way
Possibly this could be suggested as a feature (not sure how one would go about it tho) but I guess if one was using it dynamically there still might be cause for a teardown to trigger a task of sorts, as to why this doesn’t ignore the teardown after (but that’s just an assumption).

All the best

5

Let me describe our usecase a bit more.

  • A test suite with e.g. 4 test cases is started.
  • Test case #1 is executed and passed.
  • Test case #2 is executed, and Failed during setup on purpose due to scheduling a restart of the Windows. The Fail message is custom.
  • Test case #3 is executed, and during Test Setup it checks whether any test case failed with the specific
    message - if so, the Skip is called.
  • Test case #4 is executed, and during Test Setup it checks whether any test case failed with the specific message - if so, the Skip is called.
  • Windows is restarted, Test Cases #2, #3, and #4 are re-executed.

From my point of view, if you dynamically skip a test case, then you should have a really good reason to skip it instead of fail it.
Maybe even a sum of teardowns from the Settings and a Test Case would help - meaning conditioning all test teardowns in the **Settings.
I’ll try to suggest the configurability of a teardown triggerring and we will see :slight_smile:

Thank you for your time
David