Chapters
Chapters

Chapters

Hide chapters

Android Test-Driven Development by Tutorials

Second Edition · Android 11 · Kotlin 1.5 · Android Studio 4.2.1

Before You Begin

Section 0: 5 chapters
Show chapters Hide chapters

Section I: Introduction to Test-Driven Development

Section 1: 3 chapters
Show chapters Hide chapters

Section II: Testing on a New Project

Section 2: 8 chapters
Show chapters Hide chapters

Section III: TDD on Legacy Projects

Section 3: 8 chapters
Show chapters Hide chapters

Appendix

Section 4: 1 chapter
Show chapters Hide chapters

16. Strategies for Handling Test Data
Written by Lance Gleason

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In the previous three chapters, you learned how to move slow to go fast. Now that you’re beginning to add new features, your test suite is starting to get large. Lots of homeless coding companions are being placed with developers. But, as that’s happening, an inevitable problem is presenting itself. Namely, your test data is starting to get difficult to maintain. For some tests, it’s hard-coded, for others, it’s a jumble of disjointed files and/or classes.

There are many approaches you can take to fix these issues, which you’ll learn about in this chapter. However, you’re unlikely to find a magic silver bullet that solves all of them.

JSON data

In the past three chapters, you made heavy use of MockWebServer. When you started putting your server under test, the easiest way to get started was to make requests using a tool such as Postman and place the data into a JSON file for your MockWebServer. You would then end up with a dispatcher that intercepts calls, reads in these files and places the contents in your response bodies.

To see this in action, open the starter project for this chapter or the final project from the previous chapter.

Look at the CommonTestDataUtil.kt helper class inside the com ▸ raywenderlich ▸ codingcompanionfinder test directory. Looking at your dispatcher, you’ll see the following:

fun dispatch(request: RecordedRequest): MockResponse? {
  return when (request.path) {
    "/animals?limit=20&location=30318" -> {
      MockResponse().setResponseCode(200).setBody(
        readFile("search_30318.json")
      )
    }
    "/animals?limit=20&location=90210" -> {
      MockResponse().setResponseCode(200).setBody(
        readFile("search_90210.json")
      )
    }
    else -> {
      MockResponse().setResponseCode(404).setBody("{}")
    }
  }
}

In this example, you’re doing exact matches on the request path and specifying files based on the request. Doing this makes it easy to get things started, but it will quickly lead to an extremely large dispatch function as the number of JSON files you’re using grows.

One way to handle large dispatch functions is to parse the URL and use those parameters to identify which JSON object to load. For example, with the Coding Companion Finder app, you might have a dispatch method that looks like this:

fun dispatch(request: RecordedRequest): MockResponse? {
  val fileNameAndPath = getFileNameAndPath(request.path)
  return if (!fileNameAndPath.isEmpty()) {
      MockResponse().setResponseCode(200).setBody(
        readFile(fileNameAndPath)
      )
    else -> {
      MockResponse().setResponseCode(404).setBody("{}")
    }
  }
}

getFileNameAndPath(path: String) converts the URL into a file name by replacing characters.

For example, a path of /animals?limit=20&location=30318 becomes animals_limit_20_location_30318.json, and /animals?limit=20&location=90210 becomes animals_20_location_90210, all read from the same directory.

Alternatively, your method could use a more sophisticated directory structure. /big/animals?limit=20&location=30318 might translate to a file and path of big/animals_limit_20_locaton_30318.json, and small/animals?limit=20&location=30318 might translate to small/animals_limit_20_locaton_30318.json.

Post requests

Up to this point, your MockWebServer is only dealing with GET requests. It’s time to look at how to handle POST requests.

Hard-coded data

Another approach you’ve used is hard-coded data. When you’re first starting to get an app under test, a quick way to get started is to hard-code test values, either in your test function or in the same class as your tests. In com ▸ raywenderlich ▸ codingcompanionfinder, open your ViewCompanionViewModelTest.kt and you’ll see the following:

Test object libraries

One way to address the hard-coded data issues is to create a test object library. This is best explained with code.

Faker

Up to this point, your actual test values have been hard-coded strings that are the same every time you use them in a test. Over time, you may run out of ideas for names. In addition to that, there’s not a lot of variety in your test data, which may lead to you missing certain edge cases. But don’t worry, there’s a tool to help you address this: Faker. You first saw this in Chapter 10, “Testing the Network Layer.”

Locally persisted data

If you have an app that locally persists data, you may have some tests that need to have the datastore in a certain state before you run your test.

Key points

  • There are no magic silver bullets with test data.
  • JSON data is great for quickly getting started with end-to-end tests but can become difficult to maintain as your test suites get larger.
  • Hard-coded data works well when your test suite is small, but it lacks variety in test data as your test suite grows.
  • Faker makes it easier to generate a variety of test data for object libraries.
  • Tests that need to get data stores into a certain state can be expensive because you need to insert data into the data store programmatically.

Where to go from here?

Wrangling your test data is another way that you’re able to move slow to go fast. In your case, going fast means more companions in homes and programmers with higher quality code. To learn more about Faker, check out the project page at https://github.com/DiUS/java-faker.

15. Refactoring Your Tests
17. Continuous Integration & Other Related Tools
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now