UI testing with Espresso – Android Testing Patterns #2

writing good tests can be a challenge and writing reliable UI tests it's substantially more difficult user interfaces are asynchronous driven by events transitions and

data loaded from background threads coding around that without any help from a UI testing framework would require a lot of boilerplate and handling of edge cases on the other hand say I give you a phone with a sample app and tell you to test a feature of the app that I just implemented for example please make sure that saving a new note in my note-taking app works what would you do well I'm pretty sure that you would look for a Save button once you've found it you tap on it and then check if the note is present in the list of saved notes that's actually a pretty good scenario for a UI test and it's simple to understand for a person but how would we go about expressing it in code the espresso framework was created specifically for this purpose to enable developers to write UI tests that are concise reliable and using a fluent API and most importantly espresso takes care of synchronization with any UI events so that in most cases you don't have to worry about any viewstate transitions and implementation details looking back at the simple UI test we just defined we can see that the basic flow when using espresso is exactly the same as in our real life scenario first find a view using some matching rules then perform an action on it and finally verify the resulting state before I go any further and start writing actual test code let's make sure that the Android test Runner and espresso dependencies are configured in build.

gradle I'll add the dependencies and setup the runner here if you're using a version of Android studio that lets you select the test artifact remember to switch to Android instrumentation tests under build variants I'm using Android studio 2.

0 which has a combined view for both local and instrumentation tests so I can already see both in my project view instrumentation tests go under the Android test source set so I'll create a sample test glass here a name it notes screen tests I have to add an annotation on the test class to specify that I will be writing Ju ins for tests and running them with the Android J unit forerunner the notes screen in our app is contained in the notes activity by adding an activity test role I'm telling the runner to launch the activity before any tests and turn it down after they finish all this is taken care of with this line now I'll add a new method with a descriptive name for the actual test and start with the basic structure I explained before notice that on view is actually a method on the espresso class but across my testing code I will use static imports to be able to express the tests in a more concise way alright let's go through the arguments next we need a matter in order to find a view in the current view hierarchy espresso comes with a set of built-in matters for common view properties like with ID with text is checked and many others we provide a simple cheat sheet so you don't have to go digging through the documentation every time in my case I want to locate the floating action button which fortunately is the only item on the screen with the ID fab add notes now that I've isolated the view that I need using matters it's time to apply a view action or in other words a user interaction that will be simulated by espresso I just want to click the fab but again there are many more built-in actions like typing and even finger swipes that I can use to interact with views and finally I verified the outcome of my actions by using a view assertion since I want to check if an input field is shown on screen after pressing the fab I'll move this block of code here and I use the matches assertion that accepts a view matter so to summarize what we have so far the first statement matches a floating action button and clicks it which should bring up the add note screen the second statement finds the edit text that lets a user enter a note title and verifies that it is displayed using the matches view assertion notice that I didn't have to write any code in between to wait for previous events to finish as espresso already takes care of that for me to run the test I right-click on the test class and select run because it's an instrumentation test it requires an emulator or physical device I can see the actions on the screen as they execute here's a slightly longer test that includes typing into the ED notes screen and saving a note all using espresso unless you're writing end-to-end tests you should keep your test small and scoped which will make them more reliable if you want to practice adding and running UI tests on your own I suggest you check out our Android testing code lab which I based this video on it contains a downloadable project and step-by-step instructions to get you started join me for the next episode of Android testing patterns to learn how to handle adapter views in your tests good luck and happy testing you.

UI testing with Espresso – Android Testing Patterns #2

Comments

Post a Comment

Popular Posts

Turning the Page: Migrating to ViewPager2 (Android Dev Summit '19)

Android 10 is out! – What's New?