16.
Strategies for Handling Test Data
Written by Lance Gleason
Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as text.
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.
class AuthorizationInterceptor : Interceptor, KoinComponent {
private val petFinderService: PetFinderService by inject()
private var token = Token()
@Throws(IOException::class)
// 1
override fun intercept(chain: Interceptor.Chain): Response {
var mainResponse = chain.proceed(chain.request())
val mainRequest = chain.request()
// 2
if ((mainResponse.code() == 401 ||
mainResponse.code() == 403) &&
!mainResponse.request().url().url()
.toString().contains("oauth2/token")) {
// 3
val tokenRequest = petFinderService.getToken(
clientId = MainActivity.API_KEY,
clientSecret = MainActivity.API_SECRET)
val tokenResponse = tokenRequest.execute()
if (tokenResponse.isSuccessful) {
// 4
tokenResponse.body()?.let {
token = it
// 5
val builder =
mainRequest.newBuilder().header("Authorization",
"Bearer " + it.accessToken)
.method(mainRequest.method(), mainRequest.body())
mainResponse = chain.proceed(builder.build())
} }
}
// 6
return mainResponse
}
}
fun dispatch(request: RecordedRequest): MockResponse? {
val headers = request.headers
// 1
if(request.method.equals("POST")){
if(request.path.equals("/oauth2/token")){
return MockResponse().setResponseCode(200).setBody(
"{\"access_token\":\"valid_token\"}")
}
}
// 2
val authorization = headers.values("Authorization")
if (!authorization.isEmpty() &&
authorization.get(0).equals("Bearer valid_token")) {
return when (request.path) {
"/animals?limit=20&location=30318" -> {
MockResponse().setResponseCode(200).setBody(
CommonTestDataUtil.readFile("search_30318.json")
)
}
"/animals?limit=20&location=90210" -> {
MockResponse().setResponseCode(200)
.setBody("{\"animals\": []}")
}
else -> {
MockResponse().setResponseCode(404).setBody("{}")
}
}
} else {
// 3
return MockResponse().setResponseCode(401).setBody("{}")
}
}
val tokenRequest = petFinderService.getToken(
clientId = MainActivity.API_KEY,
clientSecret = MainActivity.API_SECRET)
private val petFinderService: PetFinderService by inject()
fun nonInterceptedDispatch(
request: RecordedRequest
): MockResponse? {
val headers = request.headers
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("{\"animals\": []}")
}
else -> {
MockResponse().setResponseCode(404).setBody("{}")
}
}
}
val dispatcher: Dispatcher = object : Dispatcher() {
@Throws(InterruptedException::class)
override fun dispatch(
request: RecordedRequest
): MockResponse {
return CommonTestDataUtil.nonInterceptedDispatch(request) ?:
MockResponse().setResponseCode(404)
}
}
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:
class ViewCompanionViewModelTest {
// 1
val animal = Animal(
22,
Contact(
phone = "404-867-5309",
email = "coding.companion@razware.com",
address = Address(
"",
"",
"Atlanta",
"GA",
"30303",
"USA"
) ),
"5",
"small",
arrayListOf(),
Breeds("shih tzu", "", false, false),
"Spike",
"male",
"A sweet little guy with spikey teeth!"
)
@Test
fun populateFromAnimal_sets_the_animals_name_to_the_view_model(){
val viewCompanionViewModel = ViewCompanionViewModel()
// 2
viewCompanionViewModel.populateFromAnimal(animal)
// 3
assert(viewCompanionViewModel.name.equals("Spike"))
}
}
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.
object AnimalData {
val atlantaShihTzuNamedSpike = Animal(
22,
atlantaCodingShelter,
"5",
"small",
arrayListOf(),
shihTzu,
"Spike",
"male",
"A sweet little guy with spikey teeth!"
)
}
object AddressData {
val atlantaAddress = Address(
"",
"",
"Atlanta",
"GA",
"30303",
"USA"
)
}
object BreedsData {
val shihTzu = Breeds("shih tzu", "", false, false)
}
object ContactsData {
val atlantaCodingShelter = Contact(
phone = "404-867-5309",
email = "coding.companion@razware.com",
address = atlantaAddress
)
}
class ViewCompanionViewModelTest {
@Test
fun populateFromAnimal_sets_the_animals_name_to_the_view_model() {
val viewCompanionViewModel = ViewCompanionViewModel()
viewCompanionViewModel
.populateFromAnimal(atlantaShihTzuNamedSpike)
assert(viewCompanionViewModel.name
.equals(atlantaShihTzuNamedSpike.name))
}
}
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.”
testImplementation 'com.github.javafaker:javafaker:0.18'
androidTestImplementation 'com.github.javafaker:javafaker:0.18'
val faker = Faker()
val fakerAnimal = Animal(
faker.number().digits(3).toInt(),
fakerShelter,
faker.number().digit(),
faker.commerce().productName(),
arrayListOf(),
fakerBreed,
faker.name().name(),
faker.dog().gender(),
faker.chuckNorris().fact()
)
val fakerAddress = Address(
faker.address().streetAddress(),
faker.address().secondaryAddress(),
faker.address().city(),
faker.address().state(),
faker.address().zipCode(),
faker.address().country()
)
val fakerBreed = Breeds(faker.cat().breed(),
faker.dog().breed(), faker.bool().bool(), faker.bool().bool())
val fakerShelter = Contact(
faker.phoneNumber().cellPhone(),
faker.internet().emailAddress(),
fakerAddress
)
@Test
fun populateFromAnimal_sets_the_animals_description_to_the_view_model(){
val viewCompanionViewModel = ViewCompanionViewModel()
System.out.println(fakerAnimal.toString())
viewCompanionViewModel.populateFromAnimal(fakerAnimal)
assertEquals("faker", viewCompanionViewModel.description)
}
Animal(
id=798,
contact=Contact(
phone=1-256-143-0873,
email=malinda.hoppe@hotmail.com,
address=Address(
address1=09548 Wayne Dale,
address2=Suite 523,
city=Charitybury,
state=West Virginia,
postcode=30725-9938,
country=Northern Mariana Islands
)
),
age=0,
size=Synergistic Wool Bottle,
photos=[],
breeds=Breeds(
primary=Khao Manee,
secondary=Sealyham Terrier,
mixed=false,
unknown=false),
name=Miss Linnea Hills,
gender=female,
description=For Chuck Norris, NP-Hard = O(1).)
assertEquals(fakerAnimal.description,
viewCompanionViewModel.description)
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.