| Start | ||||||||
|---|---|---|---|---|---|---|---|---|
| MockWebServer example In case your activities, fragments and UI require some background processing a good thing to use is a MockWebServer which runs localy on an android device which brings a closed and testable enviroment for your UI. https://github.com/square/okhttp/tree/master/mockwebserver (opens new window) First step is including the gradle dependency: Now steps for running and using the mock server are:
This is nicely explained in the github page of the mockwebserver but in our case we want something nicer and reusable for all tests, and JUnit rules will come nicely into play here: Now lets assume that we have the exact same activity like in previous example, just in this case when we push the button app will fetch something from the network for example: https://someapi.com/name (opens new window) This would return some text string which would be concatenated in the snackbar text e.g. NAME + text you typed in. I would suggest wrapping the dispatcher in some sort of a Builder so you can easily chain and add new responses for your screens. e.g. |
||||||||
| IdlingResource The power of idling resources lies in not having to wait for some app's processing (networking, calculations, animations, etc.) to finish with ImplementationThere are three things that you need to do when implementing
Now you should create your own logic and determine when your app is idle and when not, since this is dependant on the app. Below you will find a simple example, just to show how it works. There are other examples online, but specific app implementation brings to specific idling resource implementations. NOTES
ExampleLet us say that you have an activity which does weird stuff and takes a long time for the fragment to load and thus making your Espresso tests fail by not being able to find resources from your fragment (you should change how your activity is created and when to speed it up). But in any case to keep it simple, the following example shows how it should look like. Our example idling resource would get two objects:
Now that you have your UsageLet us skip the entire test class setup and just look how a test case would look like: Combination with JUnit ruleThis is not to hard; you can also apply the idling resource in form of a JUnit test rule. For example, let us say that you have some SDK that contains Volley in it and you want Espresso to wait for it. Instead of going through each test case or applying it in setup, you could create a JUnit rule and just write: Now since this is an example, don't take it for granted; all code here is imaginary and used only for demonstration purposes: Syntax
RemarksJUnit rules:As you can see in MockWebServer example and ActivityTestRule they all fall under category of JUnit rules which you can create yourself which then should be executed for each test defining its behaviour @see: https://github.com/junit-team/junit4/wiki/rules (opens new window) AppiumParametersSince parameters have some issues placing them here until documentation bug is resolved:
|
Read Article
https://develop.horje.com/learn/1434/reference