 Hey there. My name is Swami Mukherjee and I head product at apti.io. We are in a digital adoption space and I will talk about more of the things in our, in this particular session. But first of all I would like to welcome all of you to the OpenJSworld 2021 conference and hope you all are doing fantastically well and hope your loved ones are healthy during this pandemic. I hope you are having a great time listening to all these great speakers that we have today and I am sure that you know everyone is so fantastic. Alright so let's go ahead and see what I have. First of all I would like the organizers to giving me the opportunity to speak in this conference. Today I am going to speak on a topic which is how we can wrap web driver ive and create your own framework. When I started with this tool I faced a lot of issues getting started with the PUC as there were less documentation mostly to customize things and write things over top of the framework. Another challenge was that nobody was discussing use case around this tool and everyone was only discussing their issues in the channel and of which only a handful will answer my queries. Another challenge was that anyone whom I have asked about using this tool everybody preferred to use either Cypress or Protractor and not WebDriver I.O. I got pumped up and took it as a challenge as I know for sure that this is going to be very very simple but being portrayed as very complex and I am sure that I will work with this tool and will also start contributing to the documentation future on this tool and talk about various topics like how to create a framework in how to do your framework development on this tool and talk about integrations customizations and what all and what not. Just to give you a background how I started with this PUC that when I joined my organization we had a challenge because we had three set of applications one is on the electron is an electron based app second one was the reactive web app and the other one was browser extensions now this is not this is not this is a unique composition that this company has and it was quite tedious and challenging for us to automate so I was looking at a simple alternative you know of this of a tool you know who can who I can leverage and automate all the three sets anyways so let's go ahead and talk about the agenda we'll talk about I'll talk about you know why I chose web driver over other tools this is because that people should know that what are the intentions behind this behind choosing this tool and why we should use this particular tool second I will talk about a shipable framework wrapper which I have created over web driver IO and you would see that how simple web driver IO tool is that it gives you so much flexibility to work with and how easily we could have built this particular framework for our company last but not the least I will show a demo where I will go through some code snippets and we'll talk about I will run a use case and then it's an alive use case on my on my company's app as to how we are automating the things alright okay so now let's see why I have actually chosen this tool and why I am saying that this tool is so flexible and easy to use and quite also quite flexible on customizations etc if you get a little guidance which you can get from the current documentation you will be able to easily work with this particular tool in this talk I will talk about things that we have done to make this tool flexible in the usage for us especially across browser extensions the react web app and also an electronic ASAP I'll also talk about how our wrapper which is how is our wrapper structured how is our pipeline looks like we will also push we'll also push it to the standard documentation at the end of this particular conference so that people can go ahead and look into the customizations that we have done and we have contributed to a private IO and on June 2nd while you are listening to this particular cast you would basically also see that this this this is being open sourced as well so that people can go and try use to use this wrapper you know and and see how flexible it is to work with web driver IO alright alright so why why I chose web driver IO the tools is one of the things that we had to look as is that our developers and our technology is based on JavaScript sort of native development technologies in JavaScript so we wanted a tool which can support this particular thing and as a best practice in automation you know we always need to merge our automation code in the dev branch you know so that you can build your code along with along with the test code and then those tests can be triggered so most of the companies I have seen is that they will create a framework in some different technology and the basic logic something different and then that it's not much flexibility that you can merge them together and run it as a package kind of thing but but we do not want to make that mistake the second thing is that why we chose web driver IO is is because that our main component or is the desktop app is based on electron chairs and we used a framework called a spectrum which is written over web driver IO and since these two goes hand in hand and with fantastic integrations in place we could basically achieve the electron chairs automation as well also we wanted our developers to write our tests in future and that is also that is also a requirement that we may have in the future where in the developers can also write and contribute to this JavaScript since it is based on JavaScript third thing is that you know we extensively use react.js and Angular core libraries and that is where we would need some tool to basically help us one more thing which is which is important for us is to achieve end to end automation because as I said that we have electron chairs and react web and we also have browser extensions and we want to run end to end test cases and we wanted one tool one single tool which can support all this so this is why we have chose web driver IO we majorly use core react and Angular components as I already said and and that is why we we wanted to use the web driver IO we go next okay we want some tool which can seamlessly have integrations with the reporting tools cross browser on demand platforms and various others so if you look at web driver IO's architecture it is mostly service based or plugin based I would say when you can just hook in a plugin and you get get to go nothing fancy it's very easy to use and and and since that driver is web driver IO is based on plugins and each component is a plugin which makes it extremely flexible we also want a tool to basically which can run on web driver IO web driver protocol why is that so because web driver is evolving and we don't want to use a tool which can say after a year that we are a we are end-of-life cycle like for an example protractor now whoever it was using protractor has now maybe in fix what to do and how we can migrate and what all in what not so we want to use a tool which can be driven on the web driver protocol and supports it the final aspects that we have thought about is that the tool needs to be fast and we have seen this it's extremely fast it should be free to use it's not like any other tool in the market like Cypress who has got a licensing over the things and it needs to be truly truly open source you know and and that's our philosophy because we also work with open source and contribute to open source and since the philosophy matches with the creator of this tool you know we have chosen this the last not what the lot not the least you know it's extremely customizable I would say okay if you go next I'll talk about the shipable framework wrapper that we have why do we say that you know we want a shipable wrapper most of the frameworks in the world are so tightly coupled that each team write their own framework for their project which makes it difficult to unify and and run the end-to-end test and this has happened in in a lot of consulting that I have done is that you know every team has their own framework and at the end they have a common problem how to integrate and run it as end-to-end we also want consistency in what we do at APTI and hence we split the framework into two components which is a shipable based framework that means any project that we start here can can can basically consume the shipable base framework and then can implement their project related stuff so which can later be consumed by any implementation project and can there be only minimalistic changes that are required for that project implementation perspective we have a team who basically contribute to the shipable based framework so we keep on writing our libraries and everything so the shipable based framework consists of an engine so that engine is responsible to gather the configurations understand what spec to run which environment what browser versions what cloud platform whether it is device whether it is web so all sort of computation combination that engine would decide so that's basically a runner secondly there are base configurations which are being stored in any apple file that means like for an example a simple example would be would be delay right so across the framework how much is the delay and then you can override it in your implementation and you can you can see you know how much do you want the shipable based framework has got all the integrations in place that means it has integrations to central login which we do it in elastic search and then we have we have standard reporting which is also centralized and we basically sends all our data to Kafka queue and then later on a beautiful you know report generates and and we keep centralizing our data each time because we run our ML models and so we'll in the future slides I'll show what we do and the finally in this base shipable framework what we have is the brace framework library which is nothing but your getters at us your selects your sets and everything so all those standard functions which are which always needs to be should be present in the ship well framework we also have a feature wherein we can do auto healing all those things also sits in the base framework library what goes into the project implementation is the team who is consuming the shipable based framework they just have to create their tests they need to run they need to create their own business libraries and they need to also make those customized custom configurations which is nothing but environment browsers versions specs and what all and and cloud platforms and etc let's talk about the framework wrapper stack and why is this important so engine is nothing but an integrator or orchestrator the engine responsibilities to drive the test by looking into the base configurations and then go through the custom configurations and plug in the right set of plugins in the test execution process it is the one which will make sure whatever you have written in the custom configurations it will take care of it will initialize the web driver config file and then instruct it to execute this in turn runs the automation pack the spec then use the base framework libraries to call the reusable methods which are common throughout the framework and also call the business libraries which consist of the application flows and the logic pertaining to the application so we define different components in the business libraries and then we call those components in so into our automation script so all those dark ones here are all shipable framework components the blue ones are all the project implementations we use to test framework the favorites web driver i1 spectrum and then application under test components are the browsers and the electron app but interestingly we have extensions and we have an injected script and you will see in my particular screen you know when the things would pop up that how the extensions are being loaded and all so web driver i1 spectrum is an underline tool integrated in the same framework to support automation on browsers and electron app and here through web driver extensions which are installed on the go and seamlessly as well JavaScript is injected in the application under test unfortunately i cannot show it running on the live environment but i will discuss about how the customizations are done with web driver i1 going forward in the demo and run through the sample report execution executed against the live product i will also execute the framework on the live application that we have and to make you understand how the configurations can be made and the automations can be achieved now just wanted to go through our execution pipeline so that you have an understanding of what we do in apti let's quickly talk about how the execution pipeline looks like we have GitHub actions as a primary CI tool and you know as a pull request is machine master the pipeline gets triggered the code is an instrumented and deployed why we want to do this because we want to have code coverage at the end of each run because that goes into our ML models and and and valuable information comes out we always make sure that when we run our test on a clean environment as always the data issues are really really painful to fix we wanted to have a clean environment so while we do deployment we the next step is that we will load our master data and then you know attach and and and then the engine gets attached with the configurations and the specs the engine knows what's to pick up and where to put and what to run but key here is that we always run it on the clean environment so that we're absolutely sure that the issues that are coming are with respect to the scripts or with respect to the or with respect to to the environment and what all the tests are then executed across various browser versions platforms multiple browser extensions we have an auto healer which can understand about failures pertaining to the objects and auto hill scripts in real time so that's a small caveat there and then the results are logged and then push into a centralized location and we basically extensively mine our results we specifically pick up the data of results and logs and pass it to the ML model to tag the most important test that executed for the build do productive analytics to fetch and perform analysis on the runs and failure results we also determine that the builds are stable enough to continue testing on the same the logs from both environments and and and the production is then correlated to identify new tests and on the basis of test runs the CI is then continued or being stopped to do for the running of the pipeline so ML model has got huge influence of what we do and and and based on the decision being made by the the algorithm we basically mark our build green amber and red and and and and believe me we are 96 percent accurate on what we do right now in our automation uh having said that uh we have very less time so let's quickly jump up to the demo let me quickly share my studio uh let me quickly show you what we have so so this is the this is the framework project and if you look at it we have apt framework uh which is nothing but the the shipable wrapper that's that's what i was telling you uh you can see hello report here why is because i executed in local uh but but actually it gets centralized so we have library here which is a base library which is nothing but our uh the the custom uh functions or the reusable functions which we can we call it in our uh in all in in our scripts uh we have props uh which uh we are with which basically holds our credentials and and some framework related properties uh we have uh source so what we do is we basically define all our components uh in in in the separate file and then uh we have uh configurations now what you have done is we have split these configurations into two part one being uh the application level configurations and one is a framework level configuration these are project level if you look at it you would basically see that uh we have got uh the configurations and what we have seen is that we have uh we have basically defined different variables here so what our master script does master scripts uh looks into this particular file first and see whether they need to open up an extension whether what environment to run uh whether they need to run it on local or lambda test or browser stack or local or in any of the cloud platform and then uh and then you know the run configurations which is nothing but uh what platform what version uh what browser you need to run and then what spec to run uh what's are the base URLs that we have and then the extensions that are being will be used okay uh we'll not run it on lambda test right now or source labs but but this is just for the demo purpose um interesting so now we have extensions which holds extensions for us we have project library uh and this project library consists of our business functions uh we have pages uh which holds our objects uh and then we have specs uh which is our cases uh so what we do is we basically write our cases which basically calls the components and then we call the pages for the objects and likewise so now anyone who is actually implementing our base uh shipable framework they just need to create a source directory and all those things and and that's about it and and then it is seamlessly can connect with the abt streamer or the shipable chamber uh we have an abt master file uh this is what is the master file that i was talking about and this is uh basically uh that it will read through uh the config file here okay and create configurations file which can later merge with the web driver uh contract j s file so if i go to the abt master you would see that we have written a merge feature here which can basically take the web driver i o config and then merge it with our uh configurations which we have set above and read through our uh config file um and obviously these are different runners that we have used and and likewise so we have browser stack lambda test and source labs uh we also have uh this web driver i o config which is a base configurations we just have some hooks written here which is after test and and you know after suite suite uh where in what we do is we basically picks up the results and push everything up uh in the in the uh in the back end uh for analysis um so this is very clean this is there is nothing in it but what we do is since web driver i o only understand this particular file we basically create our own configurations uh and then merge it with this particular file and then execute it so that's how we basically wrapped uh web driver i o configurations with our configuration which are custom configurations so when you would start using this you can create your own uh set of attributes and the the master script will take it over from there okay so this is uh our project structure uh let me quickly run run run it for you okay um so i'll just put a command here the site um so it started executing uh and this would basically basically create this will open up the browser for us and you would see here there is a small icon which is nothing but an extension and here the extension is being loaded this is apti's apti client and now it is running some tests so let's wait for some time to just take uh some few seconds now so it's done it's going for the second one second test so it's passed and now uh what what would have happened is uh it would have pushed in all our results into the backend uh but uh so it's generating the results and i'm i'm i'm running this on local and that is the reason i can't show you the backend because of our IP so once the report is done uh we we then analyze and then our machine learning model takes care now uh coming back to the particular framework uh if you see uh it's quite clean uh it's easy to use and uh if i go to package.json and one of the thing that i that i wanted to show is these are all the dependencies so what you do is you just need to do and you install it install all the packages that are required and that's about it and if you look at it uh uh these are individual services that we are using and uh and how easy it is like you know if if i want to now use uh uh a service uh of web trauma i would just need to hook into package.json that's about it and then and then then put it into our into our framework so this is what i have uh for today and uh uh thank you very much for uh giving me the opportunity to to speak in the OpenJS uh conference and and uh if you guys have any questions going forward uh please uh feel free to reach me on my Twitter and LinkedIn and i'll be very happy to to to answer all your queries and and please try this particular shipable wrapper and do let us know your feedback. Thank you very much and please be safe in this pandemic all the best. Bye.