Using ATF for Long Workflows/Complex Applications

[Peter26]

Greetings,

We have a complex custom app in ServiceNow that includes a large number of workflow steps, with a significant amount of testing needed at each step.

My question is whether it's possible to effectively test through such a workflow with ATF. I can't create a different "Test" object for each workflow step because data is rolled-back at the conclusion of each "Test" object, including data about the state of the workflow context. And trying to create a single test for the workflow would lead to having hundreds of "Test Steps" -- obviously, not feasible or maintainable.

I'd hoped that "Test" objects could be hierarchically embedded with state preserved in the context of the root "Test" object, but apparently that's not part of ATF. The only other option that I seem to have is to do A LOT of scripting steps -- which is also not very maintainable and  probably defeats the purpose of using the tool. 

I'd love feedback from anyone that's dealt with this kind of situation, as well as feedback on whether ATF can be used for detailed workflows in this way, or if it's mostly targeted towards "point-in-time" testing.

[Aoife]

I would definitely make one test per step.  Also, probably one test per path per step.  Typically I only test happy path, but sometimes need to test failure paths as well.

Look for creative ways to break down the test to as simple a test as possible.  Don't try to eat the elephant all at once.

Then put all the tests into a Test Suite.

Aoife

[Peter26]

Hi Aoife,

Thanks for your response 🙂  The problem is that, if I understand correctly, I can't create a unique "Test" object per workflow step because, at the end of each "Test", all of the state is rolled-back, including the workflow context, even if all the "Test" objects execute within a given Test Suite. Thus, trying to execute any "Test" that focuses on a workflow activity occurring after the first will fail because the context of the first workflow activity won't be there.

And considering the alternative of putting all workflow steps within a single "Test", the problem is that each workflow step requires quite a few operations to be completed before it's possible to move to the next workflow step. Altogether, this could possibly result in a minimum of 40-60 test steps within a given "Test" object. Do people create "Test" objects with that number of steps routinely? Seems like this would be very difficult to maintain and/or run.

I'd be fine with creating small, self-contained tests, but without the ability to preserve context between tests within a given Test Suite, I don't think this will work for a workflow.

[Aoife]

Correct, each test has to do all the setup as all data gets rolled back.  However, you can create a copy of a test once you have the first one so you don't have to do all the steps each time manually.

Yes, creating 40 or 50 steps, if that is what it takes to do the setup to get to the actual test, is fine.  They won't be fast and I don't suggest having them setup to run automatically, but they would be find for manually run tests (like after upgrading or after making a change). 

I would not say it is routine to create such a large test, but most things just do not require that level of setup.

You could create a new test step type that has a script that does all the setup that is common and then several steps become one step.

Aoife