Yep, testing is a glaring weak spot in the android SDK. Someone, at its inception, had a vision of testing on device as the centerpiece of the whole thing, and while that's great, it's made life miserable for everyone ever since.
Ugh, Stub! exceptions. Robolectric is your friend here. You can also use it in a bare-bones mode (@Config=NONE) to speed it up... it will at least let you make tests. If it's missing a class you need, by all means, add it. They are happy to accept patches. You can also add to its runtime behavior for your own tests. In the end, however, you'll be happiest with a strong MVP implementation. Move all the interesting (testable) logic out of activities, views, and fragments into plain java classes, your presenters. The "Views" then become so boring you don't really have anything Androidy to test. We use https://github.com/square/mortar to provide scopes and structure to our presenters. After all that, think about espresso and black-box testing. Such integration tests are useful, but in practice, strong class-sized unit tests are your first line of defense. I also wrote a small treatise at https://github.com/pforhan/sandroid about this. It helped inform what we wanted Mortar to look like. Pat. On Friday, May 16, 2014 1:55:05 AM UTC-5, rakesh mailgroups wrote: > > Hi, > > I managed to get agreement from my team to try developer testing on a > feature. > > We saw a presentation on Espresso which looked really good and with > Google behind it, we thought thats the way to go. > > Unfortunately, thats when we hit issues. > > Espresso uses the instrumentation framework which essentially means we > are testing against a full apk. I really wanted to somehow mock the > model being used by Activity/Fragment but the 'hooks' to swap in your > model data don't exist. > > I've seen various hacks to get round this but nothing I was > comfortable with and would have faith the other devs would follow > properly without making mistakes. > > I could use Espresso for black box testing with customised end points > but thats what the QA automation framework does using Appium. > > The other option is to write unit tests. The main option here is > Roboelectric. Unfortunately it does not support API 19 and I can't see > when it will. > > The last fallback option is to NOT test the activity/fragment and use > MVP and then unit test the Java classes only. > > This is also far from trivial and likely to meet resistance from the > other devs who are used to 2000+ line Activity/Fragments. > > The bottom line seems to be that you have to be prepared to do ALOT of > extra work to get the code under test by developers. Add to the mix > reluctance of devs to do any testing at all, you can see why I'm quite > frustrated, especially since I championed the idea that automated > tests at all levels would solve our problems and be worth the extra > effort. > > We already have low quality and ridiculously long (manual) QA cycles > and steadily getting worse. Its really a throwback to the bad old days > that typical server side development had left behind 10 years ago. > > Any advice going forward? > > R > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
