This message was deleted.

I’ll be cautious about adopting TestFixtures, There are a few issues that were resolved after 7.2: https://issuetracker.google.com/issues/234629577 https://issuetracker.google.com/issues?q=componentid:192709%20test%20fixtures

I’m aware of the kotlin issue, none of our current test fixtures are kotlin and are all really old java based items. This is also just for

com.android.library

that is using

testFixtures

and not

com.android.test

. Whilst I can’t link code, a public Git repo that does something similar can be found here - https://github.com/emartynov/TestFixtures-test

yeah, even for java an non

com.android.test

modules, depending on the complexity of your app modules it starts to become complex pretty quickly, I’m just stating, be cautious with the adoption.

Gotcha. That’s what I’m trying to evaluate right now. I’ve already found a few gotchas in some quick conversion tests of a few small modules. For us, it’s also evaluating how much “fun” it is altering source sets and that that those altered source sets tend to not show in AS and leads to a lot of copy/paste of code people don’t need 🙂