# Stop Repeating Yourself: Sharing test code across Android Modules

DevFeed: [Stop Repeating Yourself: Sharing test code across Android Modules](<https://devfeed.tech/articles/stop-repeating-yourself-sharing-test-code-across-android-modules-25108.md>)

Original publisher: [Read original article](<http://michaelevans.org/blog/2019/09/21/stop-repeating-yourself-sharing-test-code-across-android-modules/>)

Author: Michael Evans

Published: 2019-09-22T01:34:52Z

Content type: tutorial

Language: en

Sources: [Gadget Habit](<https://devfeed.tech/sources/gadget-habit.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [build](<https://devfeed.tech/tags/build.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>)

## AI overview

This tutorial explains how to share test fixtures across Android modules using Gradle's test-fixtures plugin, introduced in Gradle 5.6. It describes applying the plugin, placing fixtures in the appropriate source set, and declaring them as test dependencies.

## Source excerpt

It seems like nowadays, the best advice is to modularize your Android app. It's a great suggestion for many reasons, including but not limited to: - improved build performance - enables on-demand delivery - pushes you to build reusable, discrete components Sounds great, right? Are there any downsides? There is one in particular which has been a a pain point for many. Often times when you're writing tests, you'll want to use some test doubles like fakes or fixtures in order to help simulate the system under test. Maybe you have a FakeUser instance that you use in your tests to avoid having to mock a User every time your test calls for one. Generally these classes live alongside tests in src/test directories and are used to test out your code within a module. For example, maybe you have a model object like: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public class User { private final String firstName; private final String lastName; public User(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } public String getFirstName() { return firstName; } public String getLastName() { return lastName; } } You might have some code in src/test that creates a bunch of fake users for your tests like: 1 2 3 4 5 class TheOfficeFixtures { public static User manager = new User("Michael", "Scott"); public static User assistantToTheRegionalManager = new User("Dwight", "Schrute"); } } This works great if you're testing code within a module, but as soon as you'd like to use these fake users in other modules, you'll note that these classes aren't shared! This code can't be shared between modules because Gradle doesn't expose the output of your test source set as a build artifact. There are all kinds of solutions for this problem out there, including creating a special module for all your fixtures, and using gradle dependency hacks to wire up source sets. However, that's not necessary anymore! As of version 5.6, Gradle now ships a new 'test-fixtures' plu