[QA] UI testing

This issue is intended to be an epic to discuss about automatic testing.

Earlgrey is the chosen tool to develop UI tests. The branch earlgrey-login contains a first draft of a couple of tests.

We can face two different targets using Earlgrey:

• UI testing: check how the app reacts to the SDK's responses. Abstracting dependencies from SDK and mocking responses make posible to isolate the app. This kind of testing complements the unit test in the SDK to have a greater coverage through the full stack of the app.

• E2E testing: the scope is the whole app, by using the SDK itself. In this case the whole stack is tested, but is more difficult to abstract tests, and positive results will not give the accurate point of the issue/bug. By using a real server, network/core performance issues can happen causing wrong positives and making the tests flaky.

The point is that we need to abstract dependencies in the app for UI testing, by making testable code.
Currently, the app calls directly the SDK interfaces to get info. We should be able to use the same calls with mocked objects, in a way similar to the following one:

1. Create mocked object(s)
2. Set the mocked object(s) with the desired response
3. Perform actions
4. The mocked SDK answers with the canned response in 2.
5. Check and assert what happens in UI

for each test. Options to achieve it:

• Put all dependencies as parameters. Therefore, by subclassing we can call the functions with mocks. Of course, this point has code design/structure implications.
• Use the SDK dependency as a mock.
• ... (more ideas here).

All additional and related ideas are welcome.

@felix-schwarz @javiergonzper @pablocarmu @michaelstingl

Start by reviewing the feature/earlgrey_login branch and its first draft of EarlGrey tests, then read the issue's discussion about isolating SDK dependencies. Done is not defined yet; the project needs an agreed approach for mockable app dependencies and a scoped plan for UI testing before implementation can begin.