Keeping things clean in test case failure conditions

The problem addressed in this paper is how to keep test case self-healing feature in hard failure conditions in a generic way. Test case self-healing feature ensures that system under test(SUT) is going to remain unchanged after successful and failed execution. This approach ensures that following test cases will not be influenced by the leftovers of previous executions.Traditional way of solving this problem is to have all possible checks in the post test case part that will ensure that specific test case execution didn't change SUT and if SUT is changed, solutions for possible failures would had to be prepared with all possible combinations. This method is very complex and hard to maintain. Examples of traditional way of solving this problem will be explained with dummy test cases written in Java/TestNG. Suggested solution for this problem is to use restoration stack. Every time test case calls an "aggressive action"(action that changes the starting state of SUT), opposite action is added to the restoration stack. Also every time test case negates already executed "aggressive action", that action will be removed from the restoration stack. If test case hard fails or some unexpected exception happens, post test case is going to check if restoration stack stores any actions for that test case and it will call opposite actions from the restoration stack with the goal of returning SUT to it's initial state. Examples of this feature will also be shown on dummy test cases written in Java/TestNG while explaining how this solution can easily be implemented with different execution engines.