 And thanks everyone for coming in here, it is evening almost end of the day and I appreciate your energy. I will appreciate one more thing if people can occupy the front seats, do not worry I will not ask any questions. So feel free because the fonts are very small and people at the back will miss the half of the slide which is down below. So there are some seats available here, please move forward if you do not want to miss something really cool. Yeah, we are going to do very cool live demos which you can directly go and use, so come fast. Alright, so this is the title of my talk, there is more in Espresso driver's element than you think slash white box testing using APM and I could have filled the title slide even more and this is very, very long, I realize it very late. So I changed it, uncover secrets of your app with Espresso driver, although still long but much clear. So I am going to talk about secret which you can uncover because every app has some secrets and every automation tool do not know these secrets. And since we are here at APM con, APM is no exception to this. There are many times when we think, oh what if APM could do this thing but it cannot and there are many times, oh I know this thing like developer has done this but APM cannot access this because app knows some things but APM does not know. So these are the secrets of the app which APM does not know about and today I am going to talk to you about how can we uncover these secrets using the latest addition to the APM family called Espresso driver and I have been fortunate to contribute this feature to Espresso driver and it's available in the latest version of Espresso driver along with the latest version of APM although in very latest version it's broken. So wait for one more release till it gets fixed, cool. So my name is Rajdeep. I work at a company called Badu which I will introduce later but I have been doing test automation from past 10 years and it doesn't look like so. I have a daughter also so I am old. And I go on GitHub by name Rajdeep V which is very not interesting. I should have some cool GitHub names I will change it soon. And if you like my talk please tweet this is my Twitter handle if you have any question after the talk you can ask me on this Twitter handle. So I work here at a place called Badu. Badu is a dating platform for those who don't know and it's not just an app it has got lots of app almost 7 to 8 apps. One of them is recently launched here in India it's called Bumble. By the way am I audible to everyone, great. So one of them is called Bumble. It's recently been launched in India doing very good it's very popular in our US market also and dating is a big business we have lots of app there and to automate these apps we use APM, Calabash, some internal tools and a lot of things and that's how I started working on APM. And so I joined this company 3 and half years ago before that I was working in India. So because they are offices in London I had to move my city. I moved to London London is very good place good climate and not very good climate though but it's very cool but good city I enjoyed it there but I missed one thing very very badly there. That was chai like here you can go out and drink chai on any any like I am a big addict of chai like after every get commit I need to go and have my cup of tea and in this city in London that if you go down the street you won't find any chai tapri there. You will find fish and chips and some crappy stuff but chai is something which I need very badly and what you get here there is like black tea which is like poison you I don't know how people drink it but that's aside. So yes and to solve this problem what I did was I make a lot of masala chai in the morning keep it in a thermal mug take it to office and keep sipping it throughout the day. But it's not as smooth as it seems right because of this mug I have burned my tongue many times like as a tester having this mishap to me is very unfortunate because I touch this mug feels very cold because it's a thermal mug and I like drink it and like suddenly it's very hot inside. The reason is because it's a thermal mug it hides the tea inside it doesn't tell you how hot the tea is or even it doesn't tell you if there is any tea left inside right. This mug actually hides the information inside this acts acts like a black box yeah and as a tester not knowing information is very limiting what if I could ask the mug like do you have tea inside or I could ask the tea are you hot and he will say yes still hot now as a tester if you had to test this mug without opening this mug apart could you could you test it like is it keeping the tea hot for long no you need to open this put thermometer inside and then only you can do this. So we don't have access to information and as a tester we really need access to information like secret as I said in the title we need some secrets so that we can do justice to testing and as an example many of you came from different places here and this is one of the good examples like how you need to look through your app or need to look through your test subject so on the airport security you might have seen those scanners you put the bag inside and these security guys or security testers just look through your bag and see are there any bugs inside sometimes they find really critical or blocker bugs like gun or knife yeah so that's how they kind of do their testing and we need something similar in our automation and what happens with APM is traditionally it's a black box testing tool and it limits the information and there are some very simple thing which it cannot do or there are times when it cannot do things very efficiently one of the example of one of the most commonly asked question is how do I get text color using APM now it's not possible if you are using like recent until recently it was not possible and second is slow or inefficient test now I'll take tell you the example of slow or inefficient test so imagine this is your app and there's a scroll view you need to scroll down until there's a item exist let's say item 420 yeah so which doesn't exist that's why the item number 420 now usually what people will do until element exist item 420 do scroll down now item 420 because of the name 420 doesn't exist so what will you do it will keep scrolling indefinite forever until the end of the world yeah so what people do is sorry they keep it in a timeout or some retry block or some various different methods but overall there is some magic number which is let's say timeout after 30 seconds yeah and there's a problem here what the problem is if element doesn't still exist because 420 doesn't exist so it will keep scrolling keep scrolling and waste it's 30 seconds properly without any doubt what this means is your test if had to fail will not fail early yeah so it's not fail it goes against the philosophy of failed fast so it's not a efficient test to write so this 30 sometimes because if the scroll view is very long people do the timeout of up to 2 minutes sometime 5 minutes depends on how crazy you are and this 30 is just a disappointment so this is not a efficient test now what if we could do something like until element exist or be reached till the bottom so if we reach bottom within 1 second or 2 second we'll say okay we reached bottom there's nothing more to see how many of you attended the talk previous to this one from then okay some of you so there was a question at the end what if the scroll view is very long or keeps load loading dynamically let's say in a dynamic scroll so a apm has this data matures strategy which then Daniel talked about but the question was very valid what if the data is loading in the dynamic runtime we don't know what data is going to be but we can still tell if we have reached the bottom of the scroll you are not can we so who can tell this to us and the question really is can apm tell us can apm not tell us but someone knows about this and that is the android operating system so in the android every view has a method if you how many of you are here by the way have developed any android application there are some of you so if you know this if you if you like if you are not a big good coder for and you can you just drag and draw down a text view basically and you can see what are the methods available on text view one of them is can scroll vertically and it's available on all the base views so the view itself can tell us can I be scrolled or not yeah and the parameter it takes is integer direction if you say public Boolean can scroll vertically so you can say can I be scroll vertically in downward direction or upward direction so the view knows it so there's someone who knows these this secret but as of now apm doesn't know it why because what apm actually is apm is not a testing technology apm is just a meaningful mediator between you as a tester and testing technology and it really depends what you are using some testing technologies like ui automator to or espresso or if you are using ios they can be xc ui test right sorry this talk I'm not going to talk about ios at all but I can take questions at the end of the talk about ios but yeah it really depends what driver you are using so most popular are ui automator 2 and espresso yeah now let's have a look at ui automator 2 and espresso did you at did someone attend a talk about ui automator 2 from shravan how many of you attended that talk if you don't know this guy shravan so he's one of the core contributor to ui automator 2 driver and just to confirm it's me again my this is me so ui shravan contributes to ui automator driver and I have contributed to espresso that's not the only difference ui automator 2 is a black box testing to know what I'm what I'm talking about is the core technologies not the apm the Google provided tools ui automator and Google provided espresso so the ui automator 2 is black box and espresso is white box so espresso scores a goal here however ui automator 2 can automate across apps but espresso driver cannot it can only automate app under test there because we already came to know in previous talks no surprises here so what we are going to do next is I'm going to show you if espresso can do white box testing how as a apm tester we can utilize this so there's a first thing and second is if espresso can automate only app under test and we are using apm how can we overcome this right so let's see this using a quick demo so for the purpose of a demo I've got one application here and the application is very simple I've got some text view here can can everyone see it yeah okay so there is a app which get got a text box which read something called welcome to apm yeah and this has some funny color the text box is not what actual good designer would do but what I have is a simple script here and as I told you earlier this will be accessing the text color of this this funny text box so what I want to do is I want to get current text color of this text box and I've got a simple apm script it's not a framework as such it's just a simple script what I do here is I just think I need to enlarge it that's better so I've got I instantiated driver and start the driver and basically here is some something which is new to apm it's called a mobile backdoor command now before I move into it let's just start a quick test so this is a simple Ruby script if you are using any other client like Java or any client it will still work so I'm using Ruby because I'm used to of it and I don't know Java so so here I am in a debugger so there's nothing fun nothing cool about this I ran a apm test which launched the app and is such sitting in a debugger now what I'm going to do is I am going to call a execute script method on this and my script is called mobile backdoor is everyone able to see this or should I enhance the form now so the script name is mobile backdoor and it takes few parameters what I'm telling is I want to call a backdoor on target element that means I want to call a method defined on an Android view and if I tell this I want to call a method on Android view I need to tell which view and here is I'm telling element ID this driver dot find element message dot ref so if you have I have to show you this this is a element and I can quickly show you which is a flash and if you see it's flashing on the screen this is one of the new feature in the espresso driver like you can flash the elements to say to confirm which element it is and this is one of the I could probably show you if I have some time but this is the reason to the why this work is because of white box so yeah so this is my element and what I want to do is I want to call method the method is an array what we can do is we can call number of methods in the chain if there are multiple multiple methods to be called which will be like concatenated methods like fluent API kind of so what I want to call is get current text color now how do I know get current text color if I refer the Android documentation here is something called get current text color it's like very small but developer dot android dot com you can see that there is a method defined get current text color on every text and I'm exactly calling this method here so this is my backdoor what I see is what I'll do is I'll execute this one and simply just you can do it in one line but to explain it better I kept it in multiple line I just call this and what I get still down but yeah what I get here is a number and this is a numerical representation of the color and all I need to do is just basically convert this in a hex value and what I get here is a 9932 cc ignore the first three bits because they are just the conversion bits to the hex representing what number it is so this 9932 cc is actually the color of the text view which is this is the activity exactly where I said the color if you see this was this was the color which was provided by Android developer so we can assert that this was the thing here to notice this is the app under test has not been changed at all it's the release version of the app as is nothing has been changed in the app to get this information cool so similar way we got this crawl view thing right which I explained during the slide so I have a script called reached bottom and it's very similar the script is very similar list view equal to Android dot find find element and the backdoor is very similar I want to call the element backdoor element ID is the reference of the element now the methods here this time is very different it's interesting that method is say the name is can scroll vertically and here the method takes argument as I told you previously so argument is type of integer and the value of argument is one it means one means can scroll down vertically in the towards bottom if it is minus one it means can scroll vertically upside towards the up so let's quickly have a look at this one reach bottom so this is a different app this time it has got a list view and I'll show you that if I execute this backdoor this backdoor can tell us whether I am at the bottom or not it's not just helpful during the scrolling but sometimes you need to just have a method in your page object scroll down till the bottom of your page or scroll down till the top of your page yeah so now I'll execute this script here and it's saying me true so it's saying yeah I can scroll to the towards bottom now let's crawl completely to the bottom so I'm scrolling manually to be sure that I reached and now it shows fault very simple very helpful but very very simple is anyone ever getting this cool so now let's move on to our next problem so I promise you I'll talk about two things one is white box testing which we just kind of covered however I just touch the tip of ice but it's much more wide and much more complex than this we can call methods in chain we can pass arguments of various types and which I'll talk about but I cannot show in the demo because it will be too tricky or people where it will fall asleep it's already to almost end of the day and second is I've been I'll not talk about how can we overcome the fact that a spread so can only drive app under test what is I have another demo so here exactly same thing same app I'm creating a driver starting the driver and there's a debugger and then if you notice there's a script and I'll just I'll just start the test so that we don't we have our environment ready so here if you see there is again a script which is similar to mobile backdoor there's a different script called mobile UI automator so what this means is we want to actually call a UI automator command using our espresso driver and I need to tell what is my how I want to call this command so this command takes four parameters first is strategy so I want to call I want to locate something whose text contains access that's the text and if you see here there are two elements whose text contains access right so I want to locate something whose text contain access and index one means there are two elements with text consent I want to locate the one whose index is one index starts from zero so I second one and I want to take action called click on that now if you see this text contains and click these are actually internal methods of UI automator to API there are more and more methods this big thing so text contains click and if I execute this script I can click on it yeah now again there are two more elements with but again there are two more elements with accessibility so sorry with text as access yeah so what I can do now is if I can call again it will click on the second one although this is part of application under test it can basically click anything anywhere on the device for example if I go to home screen there is something called maps so I will just change this to locator let's see if this works oh it doesn't I don't know why index one is out of one because there is just one so I need to give index zero yeah this makes sense and it so this was a device fired operation yeah it was not performed on app under test so this is how you can drive your outside of app boundary yeah so this is no more disappointment now how this thing works so what happens is we tell apm like hey apm I got this app called let's say app under test and I want to automate this what apm does is it says okay I have got a app called espresso server and what I can do is I can drive this app under test but I don't know anything about app under test so what apm does is it takes the package name of app under test creates a dummy manifest file puts the instrumentation information in that manifest file which points to app under test and also modifies the package name of espresso server so that it's more closer to app under test and reassigns it with the same don't worry if you don't understand these things not very important I like I like spending in some better terms later on but I had some question from people so I just want to talk about this so it reassigns both the application using the same signing key so that it becomes the instrumentation of your app under test so now what instrumentation exactly is instrumentation is androids testing support library it exposes all the interaction the system has with app under test like if your application is doing any interaction with android system instrumentation can using instrumentation you can find it out and espresso is based on instrumentation there are many other tools which are based on instrumentation like a robotium and there was one tool called calabash which was based on instrumentation I used to contribute to calabash also and one of the still one of the best tools has anyone you anyone use calabash here oh this is one so this idea of back doors is actually originally I borrowed from calabash so instrumentation is done by creating a secondary apk now that's not very hard to detect here espresso server apk is actually a secondary apk right and both main and secondary apk runs in the same process so android operating system when starts the app it starts both the apps in the same process even the process id if you see of both the process is same basically they are two different apps but running in the same process and secondary apk can if you can't see I'll read it out secondary apk like this espresso server apk can access the context of main apk which is the application under test apk because it's like instrumentation so if I have to really tell it to my grandmother I'll tell that this app and these apps are like best buddies yeah so what apm is doing it it's providing a best buddy for your application under test so let's see how the back door works so here we have apm client java client ruby club whatever client what if you want to invoke a back door and there's a apm server running no js server we say hey apm I want to invoke a mobile back door execute script with these these these parameters the method name target and everything what apm server does it okay passes on it to our espresso server apk espresso server reaches okay I need to call this method in our app under test now as I told you and here these both apps are like best friends yeah and as as with any best friends the good thing they do is they share secrets yeah and espresso server is apm's best friend so with any good friends like if they pass the secrets yeah so what really happens here is because they share the secrets espresso server ask app under test friend please invoke this method and app under test so okay cool that's how it really works now under the hood there are a lot of things happening but in in an high level if I have to explain that's how it actually works now how does the ui automator api work so espresso server apk although is the name espresso doesn't really mean it just uses espresso it has a reference it has reference to ui automator to api is also inside yeah and that's why it can actually invoke those api using ui automator to and can drive other apps like your maps Google Maps app which we saw earlier so that's how the second part works now apm element backdoor what we saw were really view functions what we could do was call some functions on android view and inside internally the espresso driver each android what we get to the in the what from the client side what we see is a selenium element object yeah but on the server side each element is stored as a android view it's a object of android dot view dot view class and therefore that's the reason we can actually call public method on these views they can be called in a chain so if I call a method which returns me another object I can call a method on that object and that object and that object and so on for example if I could check if a text is bold or not there's no direct method is bold or not on the text you what I do is I have to call text view dot get typeface dot is bold so we have to first get the typeface object which is android view which is available on android and then call the is bold or is italic kind of method on that so it can be called in a chain and it it can be passed argument so we can call any method which needs even argument but we can pass only primitive types of argument like integer Boolean string and so on or float but not some complex objects because probably server will not understand it so that was about element backdoor but there's not just element view functions there are some more backdoor so we already saw target as element in our backdoor execute script but there is something called target activity and target application we already covered target element which didn't need any modification of application under test and we could directly call it however there are two more backdoor types activity and application these are very special backdoor because they need we need to define a custom method in our activity or application class of android app and then we can call them from using these targets so basically what this means in your application class you can define a method which would say change back end URL and which will have a logic of changing the back end URL and from your automation code you can call that method by saying my target is application and this is the method name this is the parameter name this is argument type and these are the chains of method I want to call it so that's how it will work now in scope of this talk I cannot cover these two things but I'm happy to take questions later on so that's pretty much it these are some references but what I touched upon was just very basic thing however if you dig deep into android APIs there are a lot of things available on each view like you will you will be surprised at what you can do to show you some example to show you some example I have some done some really complicated thing here which is called touch substring in a text view so if you ever seen like there is a text view in which there is a link somewhere in the middle of the text which is a 10 line text view in line number 5 there is a link which you want to click ideally what will you do is you will find some magical coordinates of that text somehow and click on that but that will not work if there are the device changes if device changes or the orientation changes things will just blow up what you can do is you can use back doors here now this is a very complicated example of back door I am calling multiple back door here what I am possibly here also I am calculating the coordinates but they are so exact that what I am doing here is first I am finding my view getting compound padding left I am also getting the horizontal layout and the link index so I can say on this text view I want to find this particular substring it will give me the line number of that substring exact coordinate of that substring and those will be the exact coordinate I can call them and yeah basically that is that is how it works it is just another simple example in my opinion the way we use the back doors in our project is just enormous lot of things if I have to count number of items in a list view without even scrolling or anything there is just a method for it and there is just a method internally on android for everything so whatever you could do using just simple plain espresso with simple plain espresso use as a unit testing tool in android you can do this using APM's espresso driver so that is how powerful it is it is like the immense power in your hand so yeah that is pretty much it and thank you for being here if you have any questions please let me know ok so the question was now me wants to know more about UI Automator 2 commands because I just gave one example but there can be multiple things can be done one of the things to look out for is official UI Automator 2 documentation in android and developers dot android dot com so all the methods which are defined by our UI Automator 2 APIs on a UI object 2 can be called using UI Automator 2 driver there is also this link and all the information is probably present in the APM's documentation on the main APM website where we have documentation of all the mobile commands possibly that will be shared by Sai and Srinni in their next talk which is probably tomorrow about mobile commands in APM so the question was in the demo I used the espresso driver but I call the UI Automator 2 methods can you do Ulta the answer is no Ulta sorry can you do opposite like can you call method of espresso from UI Automator 2 driver no you cannot because that is not how it was developed so the so the fact is none of the drivers knows about each other so neither espresso driver knows about UI Automator 2 driver nor UI Automator 2 knows about espresso driver UI Automator 2 driver knows about UI Automator as a Google tool espresso driver knows UI Automator 2 as a Google tool and espresso as a Google tool both so UI Automator 2 driver knows only UI Automator 2 whereas espresso driver knows both of them but the driver themselves doesn't know each other they are different drivers completely different drivers when I talk about the word when I use the word driver the driver is different from the underlying tool itself so yeah this is a very interesting question yeah so the question was if you are switching from UI Automator 2 to espresso are things going to blow up the answer is some of the things will blow up so those things are because there in the when UI Automator 2 driver was developed there were some convenient method puts on the client side which would directly invoke UI Automator 2 scripts and those methods are not as is supported by espresso driver because those methods are not directly obeying the web driver via protocol or W3C protocol they are just a kind of a direct call direct STTP call to the UI Automator 2 server running inside the device so for example scroll is one of those things so scroll if you are using Ruby API actually doesn't really do scroll using W3C API it just does the scroll using UI Automator 2 API so those things will not work what this means is you need to change and follow the W3C API you need to follow W3C actions not even touch actions just the actions API and change your scroll implementation to that so that will work but yeah there are many small things for which will not work because they are implemented just for convenience in the client bindings not as per the protocol Keep on supporting touch actions if we move to espresso so the question was will it keep supporting touch actions touch action is not official W3C API I think just the actions is the official API so touch actions might work might not work how depends on how you just use for touch it may work but if you want to use it for scroll it may not so is APM community going to publish some set of rules I think it would be convenient because a lot of audience will be moving from I hope so but you can even raise a full request for this that's not a big deal I encourage you to do this I have seen you more questions so can I invoke a particular app activity using mobile back doors can you just start a particular app activity yeah you can but you don't really need espresso driver for this you can probably use a DD to just but yeah you can still use espresso driver to do this and second thing you like you be just show demo that we use another app we can use two apps using we can although the support is in a very weird form it's not in the web driver API form like driver dot find a limit something so you need to execute some mobile command to do this and the support is very limited so but I think most of the time you don't need to automate lot of apps it's just those limited cases for example you want to make a payment using Google play and you want to click on the continue button on that Google play pop-up which is just outside of your app these are the minor cases you usually but if you want a full-blown support of all multiple apps I would rather advise you to use two drivers so I'm just clarifying that function that you can call from the vector is it only function that few or any public function that we can define in the apps we call it in the vector both so if you want to call a function defined on Android view you will use target as element if you want to call a function defined by you in the app in the application class you can call it using target application in the back door back door parameters as long as the method is public as long as the method is public exactly and it calls it using the reflection API is there any possibility that XUITS driver could have ability like the express way no no okay thank you in future move maybe if they start using Earl gray maybe it's possible but I'm not iOS guy I'm but so for this we what we do with but especially is we have created a tiny server in the app itself which listens to the command and runs these things but for this we need we built a separate flavor of the app because it's not the real app which we deploy it's a workaround but still you cannot call private and protected method no this annotation we do not account for there is a lot of difference in the get page source because what espresso can do is it can even watch the element which are not even displayed on the page but are in the background and exist in the memory of the view of the sorry memory of the activity so it can it can give you everything which is visible let's not visible so if you have a view on top of that there's another let's say floaty it will give you everything