Work flow handling
- perhaps you should follow the Smartbear Academy courses, it will help to discover basic functiunalities of Testcomplete
https://support.smartbear.com/testcomplete/docs/working-with/managing-projects/project-editor/test-items-page.html
and
https://support.smartbear.com/testcomplete/docs/reference/project-objects/test-log/log/checkpoint.html Hi,
Generally speaking, TestComplete lacks the functionality that you are talking about despite the ages-old feature request and topics like yours asked here from time to time.
The good news is that considering your exact example, some possible options can be suggested:
a) Consider the Runner.Stop() method. If you make second test item to be a child of the first one and the third test item to be a child of the second one, then Runner.Stop(true) call will stop execution of the current test item and all its children will be skipped as well;
b) Consider the On Error and On Exception properties of Test Item. Stop Current Item setting will prevent execution of child items as well;
c) You may consider to implement a set of runtime flags (as a Project Variable of temporary type), use them as indicators and process these indicators on start of every test item to make a decision if the given test item should be executed or skipped.
P.S. My personal preference is to keep (key) data from the previous successful test item's execution and use them if current execution of the parent test item fails.
Considering your example: essentially, you are verifying three things - a) that account can be created; b) that you can log in using created account; c) that current account's information can be updated.
Assuming that the previous tests execution was successful, account's login (and supplementary information) will be preserved.
Now let's assume that account's creation functionality is broken. First test item will fail and you will be notified about this problem. Preserved account's information will not be altered, so the second test item will be able to use the login information from the previous test run and check that logging-in is still possible. And so on.
* This approach makes it possible for your tests to provide as much information about the current tested product state as possible, but not just fail miserably on first problem without letting you know the state of other functionality of the product under the test. *
