I have opened this issue:
code.google.com/p/android/issues/detail?id=21194thanks=21194
--
BoD
On 10/24/2011 09:37 AM, BoD wrote:
Can anyone confirm this?
Should I file a bug?
Thanks!
BoD
http://groups.google.com/group/android-developers?hl=en
--
BoD
--
You received this message because
Can anyone confirm this?
Should I file a bug?
Thanks!
BoD
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
I have same problem.
Any fixes?
On Oct 21, 10:39 am, BoD bodlu...@gmail.com wrote:
Hi!
I have updated my project and my test project with the sdk tools r14,
and I can no longer seem to get the tests running.
First of all, the documentation
@Elk,
This is really helpful,
I have a question regarding first approach:
Is there any other way to use Android instrumentation unit tests in
MonkeyRunner apart from starting Android tests on the device?
Can i use Android unit test methods in MonkeyRunner script?
Thanks,
On Fri, Dec 17,
Your question is vague, to me.
If you're asking how to run Android unit tests (classes in
android.test.*) using MonkeyRunner:
Set up your Android tests, then call them from MonkeyRunner. You can,
for example, write a single Python program using the MonkeyRunner API
that goes through a set of
So when you say:
In general, you test the result of a method by creating the
object with all the dependencies set to known values (the fixture),
preferably by injection. Then you call the method with pre-determined
values. Based on the dependencies as the values, you should be able to
predict
On Dec 15, 12:39 pm, Etienne lawloretie...@gmail.com wrote:
How do you go about creating an object with all the dependencies set to
known values by injection?
Depends on what type of object you're talking about, and what test
case class you're using. ActivityInstrumentationTestCase2 runs in
Nice explanation.
I'll add that when you start testing objects together, that's another
type of testing -- integration testing. For complex interactions, that
can be important to test as well.
A further bit of complexity to the picture, is that, from the outside,
you may have a single object,
I'll try to answer your last question first:
You are in Activity A, and you use startActivityForResult to start
Activity B. You handle the result of Activity B in
ActivityA.onActivityResult().
How do you test that the actual result is equal to the expected
result? In general, you test the result
Got this all working and reliably.
I still use a state variable to tell me where I am in the state
machine - not ideal.
My reliability problems seem to have been down to using
SharedPreferences to hold state between tests.
Thanks for the responses.
Ian Hunter
On Nov 29, 8:10 pm, Ian
I'm not sure that the discouragement of exit is in any written
guidelines. I just know that exiting applications is both discouraged
and unnecessary.
I did not say that *finish()* is disallowed. You certainly can use it
to close an Activity that is done with its work. It's not normally
used for
Thanks for the response.
In my test harness, I do 'button.performClick()', which itself calls
activity.finish().
According to docs...
If an activity is paused or stopped, the system can drop it from
memory either by asking it to finish (calling its finish() method), or
simply killing its
OK. Just run up the same app, press exit button and I get a call to
onStop(), then onDestroy(). That, I assume is what happens on the
finish() method. Notice no call to onPause() :-\
So, it looks like the test harness has a different behaviour.
A temporary, poor solution has been to create an
Can I get clarification here? Does your application call finish() at
some point? If so, at what point?
The Android design guidelines strongly discourage the use of an exit
button. You should see that most apps don't have one. The way to
exit an application is to switch to another one (including a
Thanks for your response - I think this could be enlightening
However, a few questions...
On Nov 29, 7:30 pm, A. Elk lancaster.dambust...@gmail.com wrote:
Can I get clarification here? Does your application call finish() at
some point? If so, at what point?
The Android design guidelines
I think AsyncTask is designed to provide a way to run things off the
main thread and take care of starting and ending the thread as needed,
but it's not intended to be re-used. It does it's thing in the
background and then it's done.
As for the test case, what you say makes sense. And I suppose
Handler has multiple constructors. The ones that take a Looper
argument can take the Looper for a Thread other than the current one.
That way you don't need to create the Handler on that Thread and it is
easier to ensure it is not null on the Thread using it. There's also
an
Actually, having thought about this more, I recall my original intent
was to only spawn the thread for the time needed to do the task. That
means I don't have to worry about shutting down or closing the thread
when the application closes. (The task responds to the application
through one or more
Re starting a thread, on most JVMs it's a relatively expensive
process, and it would be better to keep a thread warm, with a
Handler waiting, than to start new ones for every operation.
But of course that depends on how frequently you need the thread.
(Would be kinda nice if Android had an
Digging deeper into the Android source code, it looks like this must
have an active MessageQueue or it would throw an exception. In fact,
adding some logging, shows that the Looper is running and the messages
are being posted to the queue:
10-07 10:51:27.809: VERBOSE/Sample(940): Looper{437942d0}
Kind of off-topic, but why are you creating a new Thread with each
post, vs simply posting the Runnable?
On Oct 5, 5:47 pm, Jeremy Wadsack jeremy.wads...@gmail.com wrote:
I have a class that uses a Handler for a timed, asynchronous activity.
Something like this:
public class SampleClass {
Fair point. The // Do some tasks is doing long-running (Internet-
connected) stuff, so I want it to run in a separate thread. As I
understand, posting the Runnable without a thread would run it on the
main thread.
I assume the gc will clean up the Threads as they expire, but I could
also redesign
But I don't see anywhere in the Handler spec where it says the thread
will be dispatched. It appears to me that when the thread is posted,
Handler will just run its run method, without starting the thread.
If you wanted to run on a separate thread it appears to me that you'd
have to start the
Right. A Thread is a Runnable but treating it like a Runnable may not
launch it on a separate Thread. I'll re-organize this around a single
Thread.
Thanks for the code review and suggestions. Once again proving that
automated testing and code review leads to better quality code.
--
Jeremy
Come to think of it, how would one create a Handler for another
thread? You'd have to dispatch the thread and have it create the
Handler and pass the pointer back to you (we won't worry about how),
but then that thread needs to go into a message receive loop.
Apparently this is done via Looper.
I would like to point out that, as far as I can tell, you're not doing
a real unit test.
It seems that you have at least two components. So let's say you have
two, component A and component B. You would like to test both, but you
first have to call A, which calls an asynchronous process that does
On Oct 2, 9:28 pm, Alex aleksm...@gmail.com wrote:
I was wondering what is the best way to accomplish this ?
I can suggest a solution, though it may not be the best.
You probably going to have to set up some kind of listener interface
to be implemented in your unit test that triggers after the
On Apr 23, 2:35 pm, Gubatron gubat...@gmail.com wrote:
I've come to use Unit Tests organically.
Certainly I don't write unit tests first, I write tests to make sure
what I've coded works the way it's supposed to.
I also add more tests whenever I find bugs.
Of course not everything can be
I find that most of my problems are device or user specific issues.
So to be useful, the unit tests would have to run on the actual
hardware used by consumers, and would have to emulate the behavior of
real users.
Years ago, when I had to write a small bit of generic java code for
server side
Writing unit tests first to define exactly how a program will work is
nice if you have the luxury of knowing exactly how the program will
work ahead of time!
I often have a general structure for a program (game) but I don't have
all the little details figured out because things don't always go as
Well, except that you should apply your rule to unit tests, too.
I'm not sure why you'd put in weeks of development on a quad tree, and
not write tests for it. But if there's a question about whether you
want to be spending weeks of development on a quadtree implementation,
a simple
I've been a professional programmer since 1975. A lot of my
programming was done without unit testing. I now think that was a
mistake.
I'm fond of saying that programming is both really easy and impossibly
difficult. Testing is a good example of this.
But it depends on the size and
Ralf, I certainly agree that there are differences between lone-wolf
programming and for the large team. Scale, for one thing.
There are also differences between being a 14-year-old beginner, who
may someday go on to be on a team, and a programmer with decades of
experience, who can afford to
Hi Bob,
I absolutely agree that unit test can be a big win if done properly (as you
wrote this is not as simple as it looks like. The very specific corner cases
are the important test cases).
But I was specifically answering to the original poster.
For a 14 years old programmer who is starting
I routinely find a disproportionate number of my bugs and crashes
reside in the code set up for the purpose of testing and evaluation of
the program rather in the function of the program itself.
I'm sure this is a measure of my unfamiliarity with best practices,
but I find it more beneficial to
Hi Diego,
thanks for the link. I had already given them a link to your blog,
I'll send them the slideshare link too.
dagdag
Christine
On Jan 26, 2:32 am, Diego Torres Milano dtmil...@gmail.com wrote:
Hi Christine,
This presentation is very brief but could
On Jan 26, 5:25 am, Fred Grott(Android Expert,
http://mobilebytes.wordpress.com)
fred.gr...@gmail.com wrote:
you can only use those mocks supplied by google Sdk..not mockkit..
I'm affraid, that I must disagree with you:
---%
package
Thanks for the replies. Actually, I'm not stuck with testing, I use
android unit testing and I'm quite satisfied with it. Right now I'm
looking for a good intro on Android unit testing for a coworker.
On Jan 26, 12:25 am, Fred Grott(Android Expert,
http://mobilebytes.wordpress.com)
Hi Christine,
This presentation is very brief but could help:
http://www.slideshare.net/dtmilano/testing-on-android
On Jan 26, 12:44 am, Christine christine.kar...@gmail.com wrote:
Thanks for the replies. Actually, I'm not stuck with testing, I use
android unit testing and I'm quite satisfied
This can be a little confusing -- the Instrumentation class provides access
to two Contexts, one of the app being tested, and one of the instrumentation
itself. You just want to get the instrumentation's context, and the asset
manager from that.
On Fri, Jul 3, 2009 at 4:59 PM, Jeremy Slade
40 matches
Mail list logo
