If you are using the Silk recovery system (each testcase is defined with "appstate DefaultBaseState" or "appstate BaseState" and NOT with "appstate none") then there is no reason you should not be able to put your ResCloseList () in TestCaseExit. This of course assumes that you have TestCaseExit defined in your frame file.
Yes that is true. Two things:
(1) I really never "bought in" on app states myself (it's a question of style really)
(2) I assume that the base state for the second test .. test2 will take care of that for you.
However having said that if you still don't get what you need here you may want to look at test organizer for supplanting this functionality.
Again I know I don't leverage every nuance of Silk functionality out there. To me at the heart of the matter is .. can I reliably automate tests, and can I come up with a cohesive design for implementing test goals for my organization.
So I was personally always very happy with return. However I know it is always attractive to leverage the architecture as it stands whenever you can.
Rick, That's true the next testcase will set it's own base state so it's kind of redundant to have a base state set on entrance and exit. Return seems to work fine.
Regarding the ResCloseList(): If I study where the ResOpenList() calls appear and carefully place ResCloseList() before return statments it avoids the nesting results problem, only problem is when there's an exception.
I suppose that if I define my own TestCaseExit() function, I can then call the ResCloseList(), but only problem is you never know where an exception could occur so it may turn out that there is no open list so calling ResCloseList will throw another exception.
Calling DefaultTestCaseExit() gives "Wrong number of arguments error". I can't find a definition of the required args in the SilkTest help or reference. I think it wants some exception list or something.