Skip to content
This repository has been archived by the owner on Jun 20, 2023. It is now read-only.

[Debugging Trick] Use Build Scheme ENAScreenshots with specific Launch Arguments to test the user interface on the simulator #3804

Open
1 task done
ndegendogo opened this issue Nov 7, 2021 · 6 comments
Labels
alternative approaches Alternative approaches Proposals for solutions that differ from current implementations

Comments

@ndegendogo
Copy link
Contributor

  • None of the other issue templates apply to this issue.

Problem:

With the simulator you are able to test and debug a lot of the cwa code.
However, a lot of code pathes are not easy to cover.
Examples are: What happens after a green or a red warning? After a red antigen test result? After a red PCR test result?

If you are mainly interested in testing and debugging of the user interface, the following trick may help you.
Let's start with an example: You are interested to test the user interface after a green warning.

Recipe for this specific use case:

  • in Xcode, select scheme ENAScreenshots (instead of ENACommunity), and Build for Testing

Screenshot 2021-11-07 at 20 20 27

  • open file ENAUITests/Home/ENAUITests_01a_Home
  • search function test_homescreen_riskCardLow_riskMultipleDays
    The implementation sets several launch arguments, followed by the line app.launch()
  • set a breakpoint after this line app.launch()

Screenshot 2021-11-07 at 20 28 18

  • click the small triangle at the function definition to start the test, and wait till the breakpoint hits and the simulator device has launched
  • you see the green risk card, showing exposures with low risk on 4 days (according to the launch arguments).
    But the amazing part is: you can now take over, and manually test what you want (e.g. have a look at the explanations for the risk card, at the contact journal, etc)

Note: the supported launch arguments are defined in ENAUITests/LaunchArguments.swift

Do not forget:

The Scheme ENAScreenshots are configured with a focus to test the user interface.
Most of the processing "below the surface" is mocked, so you will not be able to debug the true code here.

@cwa-bot cwa-bot bot added this to ToDo in [CM] cwa-app-ios Nov 7, 2021
@whiskey
Copy link
Contributor

whiskey commented Nov 8, 2021

If you want to explore a little more freely, you can also create a custom Scheme (which is not shared) to trigger some of the mocks.

Screenshot 2021-11-08 at 16 44 04

@ndegendogo
Copy link
Contributor Author

Thanks for sharing @whiskey - such tricks are always useful 👍😅😎🎉

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Mar 27, 2022

Hey @whiskey or @ndegendogo

Do you happen to know if I can also "fake" having a positive test result in the app using this feature (launch arguments)?

I want to test #4331.

@ndegendogo
Copy link
Contributor Author

@Ein-Tim I can check in the evening after work

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Mar 28, 2022

@ndegendogo

That would be great! You can also write me a DM via Slack, if that's easier for you :D

@ndegendogo
Copy link
Contributor Author

if I can also "fake" having a positive test result in the app

Yes. Try my original procedure with this test

@30mar 30mar added the alternative approaches Alternative approaches Proposals for solutions that differ from current implementations label Apr 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
alternative approaches Alternative approaches Proposals for solutions that differ from current implementations
Projects
Development

No branches or pull requests

4 participants