System Settings Related System Test Procedures

These test cases do indeed have to do with modifying particular System Settings information like persistent login and theme changes. Such types of changes are also related to how the Settings editing widget should behave and so are also fit to unit tests.

These test cases focus on several system component interactions involving Settings changes.

---

Template for Individual System Test Cases

Test Description and Status: "A one-line description" (✅ if completed)

Steps:

1. ...

Note: These procedures do not have implementation details, but your implemented tests should follow them. Tests may insinuate using mocked or the real external systems.

---

Visual Aid to understanding the test cases here

Transporter Account Login actions

Test Name and Status: "Successfully keep account logged-in"

Steps:

1. Create a Transporter Account to use
2. Login with the Transporter Account and chose to stay logged-in
3. Close the application (this could be somewhat strange in the test)
4. Open the application
5. Verify the Transporter is not prompted to login again

Test Name and Status: "Failure to keep account logged-in notifies Transporter"

Steps:

1. Create a Transporter Account to use
2. Set up the Shared Settings to not be able to save settings
3. Login with the Transporter Account and chose to stay logged-in
4. Verify the Transporter is notified that we could not save settings
5. Verify the Transporter is still logged in for the current session
6. Close the application (this could be somewhat strange in the test)
7. Open the application
8. Verify the Transporter is prompted to login again

I believe that we would not be able to recover from such a catastrophic failure to contact saved settings. I also believe that we should not retry saving login information in case another transporter logs in during the retry interval (making retries invalid for the previous transporter).