"Unable to resolve artifact: Missing" error

[geovanisouza92]

Related to JCAndKSolutions/android-unit-test#21:

Hi guys!

Thanks for this amazing project.

I'm trying to configure the robolectric with Android Studio using the http://github.com/JCAndKSolutions/android-unit-test plugin in build.gradle, but as issue explain, I don't get it work.

Can anyone give a suggestion of how configure correctly the project to use this?

Thanks.

[mag]

Hey @geovanisouza92,

I don't know much about that plugin, but there is an official robolectric plugin for gradle. Is there a reason you can't use it?

The best way to get started with it is to clone the example project deckard-gradle and get it running. Once you've got its single test running, use it as a basis for getting your tests running in your actual project.

Unfortunately, I cannot recommend Android Studio right now; your best bet is to use IntelliJ. Any build > 135.666 should work. We are working hard to get a better experience for Android Studio users!

Let us know how it goes.

[JurgenCruz]

Hi @mag I'm the creator of that plug in. I can see that Robolectric is being run since otherwise it would not be trying to download the android-all.jar that robolectric uses. I don't think it is related to AS necessarily since gradle should work from command line. the fact that Robolectric is running means the plug-in did not fail in my opinion. What would be a cause for Robolectric not being able to download its dependencies like andrioid-all.jar?

[nenick]

As the creator you planed to improve espresso usage with your plugin? Until there I prefer a not official plugin.
For details see robolectric/robolectric-gradle-plugin#17

[JurgenCruz]

I don't plan much for my plugin actually. I'm actually in a hiatus of programming as a hobby because of my work not leaving me enough time.

[nenick]

That is ok and good to know. And I know some other are helping you to maintain this plugin.

It just make me unhappy when I see good people working on a plugin with known drawbacks. Until someone will find a way to support espresso without dependency pollution, I would prefer that all working together.

From unit test feeling, I like tests in same module. From acceptance test point of view, without dependency pollution they start and run faster.

[JurgenCruz]

I actually started a big migration a while back. My idea was to split all my code from android and make it as pure Java as I can. Sometimes even wrapping Android classes so I can mock them out in my pure java module. Then I made all Activities, Services and what not, to wire the events and everything to a handler class that has the actual logic. this way I can test the logic in pure Java. The obvious draw back is the boiler plate this require. But a good thing is that if you want to change platform, you just have to implement the "Android" classes in what ever platform you want to wire to your pure Java classes and you are done.

If my migration succeeds, then Robolectric would only be useful to test my wirings and wrappers. in which case I might as well run those tests in the emulator.

[geovanisouza92]

@mag I tried the official plugin and the sample project (but I had to copy the build.gradle instruction, because the sample does not follow the new project structure). I ran Android Studio 133.1138084 with a lot of messages saying the same: Artifact missing.

I would to like why the project need a lot of dependencies. I would like just download Android Studio, update it (what yet take a long time), open it, start a project, configure the build.gradle with some plugins and dependencies and run! Why is so hard to make it work?

Sorry for my words, but is frustrating no reach a good project design to start the real coding...

[nenick]

Try out https://github.com/nenick/android-gradle-template maybe it helps you a bit

[geovanisouza92]

Thanks @nenick I'll try just now.

[JurgenCruz]

@geovanisouza92 remember that AS is still in Beta phase. and gradle is also kind of new. so all this plugins are not actually plugins, they are more like hacking and patching being hidden in a plugin. That is why I want to change to the other approach, so I don't need robolectric nor patching (aka plugins).

[nenick]

I was thinking about same stuff and decided me for robolectric. How you already mentioned it need many effort.

But I'm very interested on your opinion when you're ready with migration. Do you feel testing is now more easy or miss you robolectric.

[JurgenCruz]

I think it is easier. since it requieres some wiring, must methods of logic become public interfaces instead of private methods in a class. so my tests can call directly this public methods to test logic, and just test interaction with a mock of the android wrapper. It depends on the abstraction level.

[mag]

My take on isolated, fully-mocked tests: The whole purpose of Robolectric is to avoid the need to fully isolate yourself from Android's APIs. That's not to say that isolated unit tests, which don't need Robolectric, are bad. For me personally, when an app becomes mature enough, I inevitably end up with a suite of tests that can live completely free of Android and Robolectric. However, if you have to do that exclusively to write any test at all, you end up with a lot of extra layers of abstraction that are painful to maintain and reason about. Frameworks should be invokable in tests, and that's why Robolectric was written (and why Robolectric 2 has real Android code in it).

@geovanisouza92 I feel your pain. @SuperJugy is right, it is early days for the AS/gradle stuff. We are working on it, and it is highly dependent on the ADT team, who are giving us support but are very very busy.

@nenick I will comment in the thread on robolectric/robolectric-gradle-plugin#17.

[JurgenCruz]

@mag I agree, Now that I'm trying to migrate, it is a pain to wrap and maintain my code working but isolated from Android. The thing is that Android forces its architecture so hard. It makes the wrapper class a convoluted code and hard to maintain spaghetti monster.

But I hope that once I migrate, it should not happen again. And having an all this wrappers that need testing, if they are simple enough, maybe I can keep testing them with Robolectric, so I'm not done with Robolectric yet.

My biggest issue is I don't have time any more at my new work =(

[geovanisouza92]

Thanks for explanation @mag and @SuperJugy . Is good to see that this "problem" evoluted to a great discussion.

My goal with this project and others is to learn how to design a good project structure, easy to learn and maintain, to use in my work, of course, and write some articles about Android development because I'd see bad (and very very poor) practices made by some developers, like to a "refresh button" pattern, adapters in main App class, singletons and hard code everywhere.

I concerned about it and try to help reach good patterns and practices to improve general app quality.

BDD, TDD, Injection, Reactive programming is kind of new for some developers and Android (mainly influenced by Java, in my opinion) as said by @SuperJugy force some things.

For example, I see a new enterprise mobile bubble, with a lot of PDV apps, made for register orders and sales, that need to be "consolidated" with server. A.k.a. click at refresh button at end of day... Bad in my opinion.

Finally, thanks for all for help. We can continue to fight with gradle and find some solution.

[ry4n1m3]

Google's gradle plugin, Android Studio, and the robolectric gradle plugin have seen a lot of evolution. Please open a new issue in robolectric/robolectric-gradle-plugin if you are still having troubles.