Hi guys. I have a prod app which currently have se...

# android

[dave]

Hi guys. I have a prod app which currently have several UI tests implemented with Espresso. Our tests are running against a kind of complex mocked dev backend. So far so good, BUT, now we are having issues with concurrent tests and the state of our dev DB in the mocked backend. we are developing Android + iOS apps and both are fighting for changing the state of our backend. Recently we decided to go for an in-app mocked server, in Android with MockWebServer by providing the raw responses as JSON. This approach seems to be correct at the beginning but while updating our UI tests it proves to start becoming very complex since the state of the backend changes according to the action of the user and in our test we can't guarantee that the proper json is ready after certain async task finishes. Do you have any advice? Do you have any idea on how are companies like Facebook, Google Ui testing their apps? Thanks, kind regards

[sergio250]

Hi David, I honestly don’t know how big companies deal with complex apps but one of my coworkers wrote a bunch of blogposts about testing real-world apps that we follow in a daily basis. The base of it all is to have a good dependency replacement mechanism to swap implementations in test time and having a clear architecture to make it easier to know and understand what’s the best scope of the tests we write. We write from screenshot tests to API tests, going through regular unit tests for our domain classes and some other integration tests for critical sections of the app like DB integration.

You can read the first post here if you are interested: https://blog.karumi.com/world-class-testing-development-pipeline-for-android/

[czuckie]

Fwiw: "good dependency replacement mechanism" is definitely a big part, followed by a good abstraction from your data fetching components.

If you have to talk about databases and/or JSON in your UI tests, you're going to struggle a lot. If you have a FooBarRepository which returns you instances of Foobar which represents a db entity, then you can have your mock one used in UI tests and a database one in prod (then you can integration test that separately)

[dave]

thanks guys, reading