For the More Curious: Espresso and Integration Testing
You may wonder why you would not retain every fragment or why fragments are not retained by
default. In general, we do not recommend using this mechanism unless you absolutely need to, for a
couple of reasons.
The first reason is simply that retained fragments are more complicated than unretained fragments.
When something goes wrong with them, it takes longer to get to the bottom of what went wrong.
Programs are always more complicated than you want them to be, so if you can get by without this
complication, you are better off.
The other reason is that fragments that handle rotation using saved instance state handle all lifecycle
situations, but retained fragments only handle the case when an activity is destroyed for a configuration
change. If your activity is destroyed because the OS needs to reclaim memory, then all your retained
fragments are destroyed, too, which may mean that you lose some data.
For the More Curious: Espresso and Integration
Testing
You may recall that SoundViewModelTest from earlier was a unit test. Your other option was to create
an integration test. So: What is an integration test?
In a unit test, the item under test is an individual class. In an integration, the item under test is
your whole app. They are usually written screen by screen. For example, you might test that when
the BeatBoxActivity screen is fired up, the first button displays the name of the first file from
sample_sounds: 65_cjipie.
Integration tests should pass when the app does what you expect, not when the app is implemented
how you expect. Changing the name of a button ID does not affect what the application does, but if
you write an integration test that says, “Call findViewById(R.id.button) and make sure the button it
finds is displaying the right text,” that test will break. So instead of using standard Android framework
tools like findViewById(int), integration tests are most often written with a UI testing framework
that makes it easier to say things like, “Make sure there is a button with the text I expect on the screen
somewhere.”
Espresso is a UI testing framework from Google for testing Android apps. You can include it by adding
com.android.support.test.espresso:espresso-core as an androidTestCompile artifact in your
app/build.gradle file.
Once you have Espresso included as a dependency, you can use it to make assertions about an activity
you have fired up to test. Here is an example test showing how to assert that a view exists on the screen
with the first sample_sounds test file name:
@RunWith(AndroidJUnit4.class)
public class BeatBoxActivityTest {
@Rule
public ActivityTestRule
new ActivityTestRule<>(BeatBoxActivity.class);
@Test
public void showsFirstFileName() {
onView(withText("65_cjipie"))
.check(matches(anything()));
}
}