Re: [bbct-list] JUnit tests and @UiThreadTest

[Code G. <cod...@gm...>]

If you find other reasons, please note them here. I will work on a wiki
page with testing guidelines as our requirements mature.


On Tue, Jan 7, 2014 at 5:39 PM, Code Guru <cod...@gm...> wrote:

> Any test methods which cannot be run on the UI thread should be clearly
> documented in the javadoc along with the reason that it cannot be run on
> the UI thread. This includes new methods added to the test suite as well as
> updating javadocs when you modify existing methods. This is most important
> on utility methods which may be used by multiple tests.
>
> In the current test suite, I see at least two reasons why a method cannot
> be run on the UI thread:
>
> 1. The method uses instrumentation to send key strokes to the app as it is
> tested.
> 2. The method uses an ActivityMonitor to wait for another activity to
> start. If the ActivityMonitor is used on the UI thread, a deadlock occurs.
>
>
> On Tue, Jan 7, 2014 at 4:43 PM, Code Guru <cod...@gm...> wrote:
>
>> All tests should be annotated as @UiThreadTest unless you have a specific
>> reason that you cannot do so, for example the test must instrument keyboard
>> or menu events. If we follow this policy, I believe that we will encounter
>> less issues with some of the tests because they run on multiple threads
>> when it isn't necessary.
>>
>> Please reply if you have any comments and or suggestions about this
>> policy.
>>
>
>