`contentpal-testing` module with test utilities about contentpal HOT 9 CLOSED

@lemonboston what's your take on this? Outsourcing looks like a cleaner solution. Do you see any downsides?

from contentpal.

I've came accross it recently that gradle introduced the api and implementation separation to have the interfaces in separate modules. Have you seen that?
I've seen this practice by the way, to separate them, in backend projects as well, back in maven times.

Those gradle changes will be introduced in Android Studio 3.0, so I think it may be worth waiting for it:
https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html#new_configurations
All gradle configurations will have to be migrated anyway and the new system may help with this particular case, I suppose. Although it could probably be done now as well, but I'd just wait a little. Android Studio 3.0 is in beta ~7, so I assume max 1-2 months before they release the stable.

from contentpal.

But I am not sure it's always worth separating the interfaces of a library though, but in any case, as you mentioned that java projects could handle that circular-like dependency, so maybe the new gradle update would enable it in Android projects as well so that Option 1 would be available to consider, too.

from contentpal.

I don't think that these new dependency types aim at this specific problem. The names of these are just poorly chosen IMO. From a developer's perspective (one who uses this library) it certainly doesn't have any benefits to move the interfaces to a separate module, because you'll always need the contentpal module too.

Anyway, I don't see any reason to wait for AS 3.0. Actually I wouldn't want to wait because we can't test all the other *Pal modules until then.

There is one more option: move the testing package from test to the main sources. But that would mean they are included in every production build (also including hamcrest and possibly junit), which I'd like to avoid.

from contentpal.

In this case I suppose it would be worth trying to solve it with Option 1. I've spent about 20 minutes now trying to make it work and I couldn't, 'sourceSets' or 'configuration' may help, not sure.

Dumping a few links:
https://stackoverflow.com/a/44364851/4247460
https://stackoverflow.com/questions/42929841/app-declares-a-dependency-from-configuration-compile-to-configuration-default
https://stackoverflow.com/questions/35794921/rootproject-in-a-gradle-module-thats-imported-to-another-project
https://softnoise.wordpress.com/2014/09/07/gradle-sub-project-test-dependencies-in-multi-project-builds/

from contentpal.

Or another option is to create the contentpal-testing module which has the test support classes in main and the tests for contentpal are in this module's test classpath. It's not where they should normally be but the project compiles and builds together anyway, right? Or not in every case?

from contentpal.

No, that latter suggestion is definitely not a good idea. Code and unit tests should really be in the same module.

Even though Option #2 doesn't have any benefits for the developer who uses the project is still seems to be the cleaner way. I mean it takes at most 15 minutes to get it working, probably even less. You've just spend 20 minutes to get Option 1 to work I've probably spend an hour or so too. Both without success.

Doesn't that tell that option 1 is probably complicated and potentially fragile? Even if we get it to work, it might be not more than a hack that could break with every Gradle upgrade. Is it worth the hassle?

Option 2 is pretty simple and straight forward. There are no real downsides. Some even consider it good practice to keep interfaces and implementations separate (that's what we do in http-client-essentials).

from contentpal.

We'll go with option 2 once #76 has been merged.

from contentpal.

Ok.

from contentpal.