Why Robo tests gets marked as passed so quickly?

Question

TL;DR

The app has tons of flows, but sometimes runs get passed faster than 2 mins...

---

Is there any way to keep it running until the timeout period (e.g. 1hr) is almost consumed? Attached a screenshot for a quick termination e.g.

Although the app is very big with tons of flows, sometimes runs get passed after 2min, 5mins but what is the critieria which decides that the running robo test should terminate now with a passed result? any idea what makes the recorded graph decides to go to this node? n.b. I assumed it's the terminal node

Answer 1

Why Robo tests get marked as passed so quickly?

It turns out that due to having a varying b.e. responses, the app journey gets changed. If there're 3 disconnected components (as in gif), what happens is sth like the app can start in any of the 3 flows resembling the 3 components. Which implies how long the journey will be

Is there any way to keep it running until the timeout period (e.g. 1hr) is almost consumed

Guiding the robo tests as explained here is a promising way to let journey bigger by following some sequence of actions which make the graph bigger

What is the criteria which decides that the running robo test should terminate now with a passed result?

Robo tests are simply applying flood fill on the app (as in gif). Where the graph nodes are represented by screens, e.g. onboarding screen, and edges are represented by actions, e.g. click on next button

Answer 2

Most likely it is always more or less the same time duration ...while the only difference may be the test's position in the queue (you're not the only user there, which is why it may appear as if the duration would vary). And that TerminatedActivity-33 only confirms that the Activity under test had been successfully terminated ...which is "The End" of the story. For reasons of efficiency, the test will terminate as soon as possible - the timeout value can only be reached when it's stuck.

That the queue may also run in parallel might be another possible cause; while then, even if the real-time duration would indeed vary, the processing time (CPU shares) would still be about the same. Disclaimer: I have no clue how it internally works, just tried to apply some common sense.