Possibility to add a test that closes and opens application

[Kendru98]

Description: Imagine that I want to test for example local storage of the app, and I want to be sure that my settings are remembered when I close and open app Example case:

1. Open app
2. Change language of the app
3. Kill App (for example native.pressRecentApps() and swipe up)
4. Open App
5. Check language

[bartekpacia]

This is an interesting use case.

The problem with it is that currently, it's impossible. That's because Flutter tests run inside the app, so if the app dies, the tests also die.

---

It'd be very cool to accomplish this use case, though.

In Patrol 2.0, native tests are already run from the instrumentation process, which is separate from the app. But what these native tests then do is gRPC communication with the app process to execute Dart tests (which run in the app process). So again, if the app process dies, game over.

But what if we could move execution of Dart tests to the instrumentation process?

---

I'm just thinking out loud.

Of course, there are many problems with that, mainly that the whole flutter_test API is built to work-in-process with the app under test. Essentially, this would probably result in flutter_driver-like approach (and problems).

[tenhobi]

We would also want to do these types of tests to for example test whether one-time profiles are not present in the second app run, etc.

[matthew-carroll]

Another use-case for this is deep links. It's important to be able to verify that a deep link is handled correctly when there's no app in memory. Flutter has different code paths depending on whether a deep link exists pre-launch vs a deep link that arrives after launch.

The problem with it is that currently, it's impossible.

I think this statement could use some elaboration. It's impossible for which system? Impossible for standard Flutter integration tests? Impossible for Patrol's current chosen tradeoffs? Impossible for any automation ever?

I doubt it's impossible in general, even if it's currently impossible given Patrol's existing architecture choices. But if there are specific Android and iOS reasons why this can't be done, I'd be interested to know exactly what those are. I would be surprised if there's no way to automate verification of something like deep links that launch an app on Android and iOS.

If it's possible in general on Android and iOS, but the problem is that Flutter tests run in-process, then that would beg the question why Patrol can't use its test runner to accumulate test results across independent runs of the app.

[matthew-carroll]

I have another use-case for this. I'm building a fasting app. It's a glorified timer. But the fact it's a glorified timer means that if the app doesn't correctly resurrect the timer after launch, the app is worthless. Thus, mission critical.

What I'd like to be able to test is:

• Start the app
• Activate the timer
• Let a few seconds go by
• Kill the app
• Start the app
• Verify that the timer is running and its value is greater than zero

There's another version of this same concern, which is a backgrounded app.

When an app is backgrounded, the OS stops the app from executing code. Therefore, in my case, my timer is paused. When the app is foregrounded again, I need to update the timer accordingly. Therefore, I'd like to test:

• Start the app
• Start the timer
• Background the app (paused)
• Wait ~5 seconds
• Foreground the app (resumed)
• Verify that the timer isn't 5 seconds behind