Roboelectric for unit testing?

[futurice]

Roboelectric for unit testing?

[djodjoni]

First of all I am using Roboelectric and I hate it, but it is useful and I will share why :)

there several statements here which are kind of too generic and not clear to me.
@luciapayo roboelectric does not really make your tests that slow but probably the speed of development of those tests is slow, which is obvious. Also wrapping too much things will cost lots of time maintaining those wrappers.
@peter-tackage there is no excuse for boilerplate :) so better somebody else do it, I hope they respect the contract as I hope the millions version of Android does too :)
@samiuelson dependency injection and mock should be used wisely and only if needed and too complicated other wise.

There is not question about that Business logic should be done in a way that it has almost and preferably no external dependencies, however there is also Application Specific Business Logic, which needs to be tested as well.

There is a bit confusion what is a Unit Test and the confusion is in 2 main points:

1. the definition of a Unit. and and in OOP is should not strictly mean a single Class. This involeves tightly the granularity of writing tests, if you go too far you are probably coupling with implementations or some internal parts of your system that doesn't really need to be separately tested.
2. the isolation of those tests. tests should be isolated in such a way that they do not interfere with each other. Isolating the Unit from its environment -> mocks -> (coupling with implementation , probability that it does not behave correctly in real environment). in other words we can still call them Unit tests without comlpete isolation.

Having said that Unit Tests may involve some android components.
Some will say "..well wrap those", but this can be really costly for a line of code you may end up creating bunch of classes in different modules coupling with Android specifics anyway And still not covering the real UI test. What I learn from experience is that no-one care of your Unit Tests, they just want the app to run as in specs, its just you who needs to maintain those tests.

So 'Unit Tests may involve some android components'.

Normally you should not mock 3rd party code(just the adapters connecting to it) as you don't know in detail how it works. Robolectric guys do exactly this and its pretty big one. They do an awesome job and yet I prefer test with a Real device using Espresso. The problem is using TDD and running tests constantly could be terribly slow so Roboelectric is of real help here.

So Roboelectric can be used for unit tests which involves android components and its way faster than Espresso (the fastest currently real UI framework)

[AlejandroHCruz]

What about Espresso and the new Espresso Test Recorder in Android Studio 2.2?

[peter-tackage]

I too have not used Roboletric in any significant way, but at the moment I can't see a place for it; given the improvement in JVM testing tools for Android and patterns such as MVP/MVVM that separate logic from platform dependencies.

I can't comment on performance, but the real issue for me is that the tests run against an approximation of Android in code that you can't control. For all the boilerplate your get in wrapping, at least you control the contract. See #114

[jaggernod]

My biggest problem with using Roboletric is that it is provided by 3rd party company. So if you now have Android N then you still need to wait for their implementation, which can take time and might not behave as a real device.

The other thing is that you shouldn't use it for Unit Tests as those are not Unit Test if you rely on the whole 3rd party implementation framework. For Integration Tests using the real software seems like a better idea.s

P.S. Making your own code independent from Android framework is also a good mental exercise.

[peter-tackage]

This is a good point about Robolectric having to play catchup with APIs and implementation.

[samiuelson]

Roboelectric is not a good approach to unit testing. App should be design in such way that business logic can be tested with junit and only some mocks. Use dependency injection in your app design, don't mess entities and business logic with android.* package classes.

[peter-tackage]

Sounds like we are all in agreement on this one.

[djodjoni]

i tried the recording and i like it. its a bit slow but quite helpful. however i believe espresso is already mentined in #114

[rhonyabdullah]

So can some explain when i should roboelectric and when i should espresso ? I'm confusing to choose the exactly testing tool.

[djodjoni]

IMO use roboelectric when you want UI related tests to pass fast for example during TDD cycles.
Espresso you can use to run big set of integration tests overnight or limited set of acceptance tests for feature validation.

Note that the main idea is to spend less time in code and tests but do more features (test covered of course) . So if using some framework is taking to much time to set up and run and the tests are flaky then you probably do not use it right or the framework is not meant to be used this way.