Data builders (experimental)

⚠️ Data builders are experimental and subject to change. If you have feedback on them, please let us know via GitHub issues or in the Kotlin Slack community.

Apollo Kotlin generates models for your operations and parsers that create instances of these models from your network responses. Sometimes though, during tests or in other occasions, it is useful to instantiate models manually with known values. Doing so is not as straightforward as it may seem, especially when fragments are used. Creating operationBased models requires instantiating every fragment as well as choosing an appropriate __typename for each composite type. Data builders make this easier by providing builders that match the structure of the Json document.

Note: previous versions of Apollo Kotlin used test builders. Data builders are a simpler version of test builders that also plays nicer with custom scalars. If you're looking for the test builders documentation, it's still available here.

Enabling data builders

To enable data, set the generateDataBuilders option to true:

1apollo {
2  service("service") {
3    // ...
4
5    // Enable data builder generation
6    generateDataBuilders.set(true)
7  }
8}

This generates a builder for each composite type in your schema as well as a helper Data {} function for each of your operations.

Example usage

Let's say we're building a test that uses a mocked result of the following query:

1query HeroForEpisode($ep: Episode!) {
2  hero(episode: $ep) {
3    firstName
4    lastName
5    age
6    
7    ship {
8      model
9      speed
10    }
11
12    friends {
13      firstName
14      lastName
15    }
16
17    ... on Droid {
18      primaryFunction
19    }
20
21    ... on Human {
22      height
23    }
24  }
25}

Here's how we can use the corresponding data builder for that mocked result:

1@Test
2fun test() {
3  val data = HeroForEpisodeQuery.Data {
4    // Set values for particular fields of the query
5    hero = buildHuman {
6      firstName = "John"
7      age = 42
8      friends = listOf(
9        buildHuman {
10          firstName = "Jane"
11        }, 
12        buildHuman {
13          lastName = "Doe"
14        }
15      )
16      ship = buildStarship {
17        model = "X-Wing"
18      }
19    }
20  }
21
22  assertEquals("John", data.hero.firstName)
23  assertEquals(42, data.hero.age)
24}

In this example, the hero field is a Human object with specified values for firstName and age. The values for lastNameand height are automatically populated with mock values. Similarly, values for the ship's speed, the 1st friend's last name and 2nd friend's first name are automatically populated.

You can replace buildHuman above with buildDroid to create a Droid object instead.

Aliases

Because data builders are schema-based and aliases are defined in your queries, there is no way for the codegen to generate builder fields for them. Instead, you'll need to specify them explicitly.

Given a query like this:

1query GetHeroes {
2  luke: hero(id: "1002") {
3    name
4  }
5  leia: hero(id: "1003") {
6    name
7  }
8}

You can generate a fake data model like so:

1val data = GetHeroes.Data {
2  this["luke"] = buildHumanHero {
3    name = "Luke"
4  }
5  this["leia"] = buildHumanHero {
6    name = "Leia"
7  }
8}

@skip and @include directives

By default, the data builders match the types in your schema. If a field is non-null you will either have to provide a value or let the default resolver provide one. This is an issue for @skip and @include directives where a field might be absent even if it is non-nullable. To account for this case, use the same syntax as for aliases.

1query Skip($skip: Boolean!) {
2  nonNullableInt @skip(if: $skip)
3}

You can generate a fake data model like so:

1val data = SkipQuery.Data {
2  this["nonNullableInt"] = Optional.Absent
3}
4
5assertNull(data.nonNullableInt) 

Configuring default field values

To assign default values to fields, data builders use an implementation of the FakeResolver interface. By default, they use an instance of DefaultFakeResolver.

The DefaultFakeResolver gives each String field the field's name as its default value, and it increments a counter as it assigns default values for Int fields. It defines similar default behavior for other types.

You can create your own FakeResolver implementation (optionally delegating to DefaultTestResolver for a head start). You then pass this implementation as a parameter to the Data function, like so:

1// A TestResolver implementation that assigns -1 to all Int fields
2class MyFakeResolver : FakeResolver {
3  private val delegate = DefaultFakeResolver(__Schema.all)
4  
5  override fun resolveLeaf(context: FakeResolverContext): Any {
6    return when (context.mergedField.type.leafType().name) {
7      "Int" -> -1 // Always use -1 for Ints
8      else -> delegate.resolveLeaf(context) 
9    }
10  }
11
12  override fun resolveListSize(context: FakeResolverContext): Int {
13    // Delegate to the default behaviour
14    return delegate.resolveListSize(context)
15  }
16
17  override fun resolveMaybeNull(context: FakeResolverContext): Boolean {
18    // Never 
19    return false
20  }
21
22  override fun resolveTypename(context: FakeResolverContext): String {
23    // Delegate to the default behaviour
24    return delegate.resolveTypename(context)
25  }
26}
27
28@Test
29fun test() {
30  val data = HeroForEpisodeQuery.Data(resolver = myTestResolver) {
31    hero = buildHuman {
32      firstName = "John"
33    }
34  }
35
36  // Unspecified Int field is -1
37  assertEquals(-1, data.hero.age)
38}