This was part of the initial plan for unit-testing support, but because of the IDEA issue you mentioned, I haven't touched the compile class path in Gradle so far. I have not spent too much time looking for a workaround, but it doesn't seem IDEA was designed to have too much separation between the compile and test scopes.
I agree with Roman here - it's not clear to me how subclassing would solve the real issue: you would still have to implement all methods that you call from production code. What we might also consider is having an android-util library that gives you the real, working implementation of Uri. But that's a different conversation. MIchal On Wednesday, February 4, 2015 at 6:38:18 AM UTC, Jake Wharton wrote: > > I'm open to other solutions and suggestions. As far as I can tell (as a > nearly-completely uninformed poker-arounder in the code), IDEA's model > doesn't allow the ability to vary the platform SDK between the main and > test source sets which would otherwise allow this to work the way you would > hope. I believe Gradle should have no problem, however (although it is > currently not doing so for test compilation as of rc1). > On Tue Feb 03 2015 at 10:32:04 PM Jake Wharton <[email protected] > <javascript:>> wrote: > >> Since test classes are compiled against the platform jar, we are unable >> to subclass some of the platform types which have final methods, are final >> classes, or have non-visible constructors. The jar that is on the >> classpath at test execution time does not have these restrictions. >> >> Because of this fact, mocking is the only approach that currently works >> for common classes like Uri and Parcel. While doable, it's extremely >> annoying due to the large surface area of these API and others like it. >> >> A possibility to alleviate some of this pain would be to allow library >> projects to compile against the test version of the platform jar. With >> this, fakes could be written and compiled as libraries without the normal >> restrictions (albeit with fair warning that this represents a deviation >> from the normal understood stability of platform public APIs). These >> test-only libraries could then be added as testCompile dependencies which >> would not be subject to the compilation problems of the regular platform >> jar but correctly apply at execution time to the test platform jar. >> >> Thoughts? >> > -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
