Android instrumentation tests - best practice for package structure

Issue

I am using espresso for instrumentation test cases. I have structure similar to the image below for my production source code:

What i would like to know is should the androidTest (instrumentation tests packages) follow the same hierarchy ? What would be the benefits ? if i dont follow the same hierachy for instrumentation tests will it lead to any scalability issues or issues in general ? Right now i have created instrumentation tests folder that is nothing like the production source code and everything works but i saw blogs where developers keep the packages aligned, why ? and to be clear, for unit testing i would keep them to same as it makes sense to match packages but im not so sure about for instrumentation tests .

Solution

Instrumentation Tests are about testing different app components working together to achieve a certain functionality such as, in the app provided, logging in. Since this is a high level overview it would make things easy to find tests for certain high level feature which would definitely contain more granular tests regarding that feature such as entering an invalid email format in the email field and so on. So personally I would think of the instrumentation tests structured as such:

androidTest
\--- java
     \--- com.example.myapp
          +--- login
          |    +--- LoginTest (Class, Scenario 1 of high level feature, ex: already signed up login)
          |    |    +--- valid_email_login (method)
          |    |    +--- invalid_email_login (method)
          |    |    \--- no_internet_connection (method)
          |    \--- AnotherLoginTest (Class, Scenario 2 of high level feature, ex: create new account login)
          |         \--- test_for_scenario_2 (method)
          \--- another_high_level_feature (and so on...)

That way the tests can be easily understood and built upon or changed as the code changes.

With unit tests, testing is made on a single (hence so-called unit) component of the app such as the LoginPresenter. Usually the test would mock up all needed dependencies for the component (probably using Mockito or other kind of mock injection) and verify that the component is behaving properly as per logic. Note that for best practices, unit tests don't need a device/emulator or activity related dependency like Context and hence the reason why an architecture like in your example MVP is needed to be able to carry out unit testing on your local machine (PC or laptop). But this does not stop you from creating unit tests within the androidTest folder, specifically in cases where you're testing a component that needs a device or emulator for hardware related component testing like NFC or GPS, etc...

So in that case I would personally end up with something like this:

src
+--- androidTest
|     |--- java
|          \--- com.example.myapp
|               +--- unit
|                    \--- (unit\component related tests that need device\emulator go here)
|               \--- instrumentation (components working together related tests go here)
|                    +--- login
|                    |    +--- LoginTest (Class, Scenario 1 of high level feature, ex: already signed up login)
|                    |    |    +--- valid_email_login (method)
|                    |    |    +--- invalid_email_login (method)
|                    |    |    \--- no_internet_connection (method)
|                    |    \--- AnotherLoginTest (Class, Scenario 2 of high level feature, ex: create new account login)
|                    |         \--- test_for_scenario_2 (method)
|                    \--- another_high_level_feature (and so on...)
\--- test
     |--- java
          \--- com.example.myapp (unit\component related tests that don't need device\emulator go under here)
               +--- presenters
               |    +--- LoginPresenterTest
               |    |    +--- view_loading (method)
               |    |    +--- disable_views_when_loading (method)
               |    |    \--- another_unit_test (method)
               |    \--- AnotherPresenterTest
               \--- models (and so on...)

With regards to different variants that your app consists of, the Android Gradle Plugin provides you with a command to figure out where to place variant dependent tests. Simply run gradlew :app:sourceSets in your project root directory and you'll get for every variant (whether its for test, androidTest or none) the directory structure for it. Check out this link for more info: Configure Build Variants. Also don't forget to checkout @Rule in JUnit while building your tests.

As a final wrap up, a link to a good Codelab example to illustrate most of the above: Android Testing Codelab

Answered By - ahasbini