preserve keychain on reset/restart on iOS for a subset of tests in a suite?

[James Stuckey]

Here's my situation:

For the majority of my tests I want the application to start up clean, at which point I will create and login as a particular user and perform one or more tests.  However, for some tests, for example testing behavior after persistence of credentials in the keychain, I'd like to be able to perform some actions and then restart the application without losing the keychain information.

I've read the documentation about the 'keepKeyChains' capability and this seems close to what I need but feels like it is in the wrong place in the lifecycle since you set it on startup but it applies to what happens when you reset/quit.  Here's what I mean...

If I create and start my driver with keepKeyChains = false (the default) everything is fine for the majority of the tests within my testsuite (where i want things to be cleaned up before and after).  

However, there is no option to the 'reset' or 'restart' commands that allows me to override this behavior at the time I issue the reset/restart.  I've experimented with creating a new driver with 'keepyKeyChains = true' and starting it but that doesn't really help since it seems that the first thing that happens is the current driver quits and since it was started with keepKeyChains = false the keychain is wiped out.  So i can't do that from within the test.  If I do this before the specific test(s) I have a simllar problem at the end, I want to clean up after the test so that I'm back in the original state with keepKeyChains = false and no keychain data.  But to do that I actually have to restart everything at least two more times (once to switch the driver back to keepKeyChains = false, and again to let it actually wipeout the keychain). This would be less of an issue if restarting the simulator/app was fast but given that it isn't there is a pretty significant penalty for all those restarts.

Perhaps I'm missing or misunderstanding something or there is another/better way to accomplish it?

Thanks in advance for any help/suggestions

-James

[bootstrap online]

This sounds like a use case for a reset command that takes parameters.

> --
> http://appium.io
> ---
> You received this message because you are subscribed to the Google Groups
> "Appium-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to appium-discus...@googlegroups.com.
> Visit this group at http://groups.google.com/group/appium-discuss.
> For more options, visit https://groups.google.com/d/optout.

[Jonathan Lipps]

What about using different sessions, with different caps, instead of a reset call in the middle?

[James Stuckey]

If I understand correctly, different sessions implies having multiple machines/VMs available since instruments will only support 1 session at a time?.  If that is the case, that isn't an option for me at present as my current goal is simply to be able to run a test suite locally on a development Mac. In the future I would like to integrate with my CI pipeline and that might be possible in that environment.  If I'm mistaken, can you point me at information on how to create/manage multiple sessions on a single machine?

-James

[Jonathan Lipps]

That understanding is correct, but I was talking about using different sessions serially, not at the same time.

[James Stuckey]

Thanks for the clarification.  I assumed you meant in parallel since I believe what I'm doing currently is to create a different session serially.  That is, what I do is to create and start another driver instance with a modified set of capabilities (is there some other way to create a new session?), run the test, then do the create/start dance again to begin a new session with the original caps.   This works but isn't quite as straightforward as it might seem as it requires several unnecessary (and slow) restarts of the simulator/app to accomplish this.  This is the basic sketch of what I do currently:

0.  at the beginning of my testsuite start a session with caps set to delete the keychain
1.  at the beginning of the test method that requires preserving the keychain, start a new session with caps set to preserve the keychain
2.  perform test logic, at one point I restart the session to confirm the behavior with the keychain preserved
3.  at the end of the test start a new session with caps set to delete the keychain again.  however, this does *not* cause the keychain to be deleted since that session was started with the caps set to preserve it.
4.  restart the session again so that the keychain is deleted

My thinking was along the lines of bootstraponline, that what I need is a way to pass options to reset and/or restart that would allow me to override settings like preserving of the keychain when the session is taken down.

With that change, this could be reduced to:

0.  <same as above>
1.  when i want to test behavior with keychain preserved, call reset or restart with option to preserve the keychain (which would override the caps setting)
2.  restart the session at the end of the test (which would honor the original caps, since no override is provided, and remove the keychain)

-James