 Good morning everybody, it's the first topic of the day, I'm going to talk a little bit about what we're going to do over. We're going to introduce ourselves and talk about what comes before doing care for this talk. We're going to go through the three principles of understanding performance and support. We're going to talk very quickly about how to test your usability and a bunch of resources that we're going to share out. We have right here, I'm a senior US designer and a technical manager, a trip advisor. We're out in Needham in case you guys are curious. And we care about US as a US designer and developer, but we're really interested in telling you what we can. We're going to talk about how we can help you guys and we can see where UX goes way beyond that. And this being an open source conference we wanted to talk about how the UX on the back end or the UX as an open source contributor is also just as important as the UX for the end user. You know, open source software is collaborative, there's not necessarily someone steering the ship all the time, unless it becomes a little bit more... If we do a better job thinking about UX up front, we can make our projects better, more usable, more contributors, more adoption. This is right up front, so you guys know we're a basic working knowledge of development best practices. If we throw out some basic development best practices, we're not going to look at some of the more confused. And if you are, we assume that you're interested in talking to a US class. We're also assuming that you are people that care about to take things from bad to good or just okay to good. And we're also assuming that since you are an open source dev conference, your project, your project, your opposition at the size of the damages... Can everyone hear me? Yeah. I think I can start. I think I can start. All right. All right. In the back. All right. All right, so good morning everyone. My name is Deepak Kall and I am a QE manager in Red Hat. And with me is Anuj, my colleague who is a developer. And I'm just kidding. He's not here. His application did not go through. And that is why the John Cena joke. His name. All right. So I have been writing tests for a living from last 13 years. And during those 13 years, I realized that we, the test automation developers, when we do things individually, we don't do things in a way which could have been done if we had done those things collectively. Like shared something with one another in the community of test automation. And this is exactly what today's talk is based upon. The end-to-end test strategies for web apps using common web components. All right. So normally what happens is when we say tests, it means different thing to different people. This is DevConf. I'm expecting there are people who are developers. When you say test to developers, it usually means a unit test or an integration test, right? It's not an end-to-end test. So Martin Fowler, who is a ThoughtWorks agile expert, he created this pyramid of testing, right? So right at the bottom was the unit test. So which were fast and less expensive. And right at the top is the end-to-end test, which is slow because it runs in a browser for a web app and is not very reliable because there's so many moving components in it. So this talk particularly talks about the end-to-end testing, the testing for a web app which you do while invoking a browser. Even though it is slow but still very important because it is as close as you get to the actual user simulation, right? All right. So Selenium WebDriver. I don't want to give you the whole history of Selenium. So there were two projects, two open source projects, the Selenium project by Jason Higgins and then the WebDriver project which got merged. So it is actually an API with which you can talk to a browser, right? To run an automated test in a browser, you need to modify the DOM, right? You need to click on buttons. You need to enter the text in a text box, all right? And this is the, actually it's an interface, but the other, the people, the browser vendors have written APIs which are very browser-specific like the Firefox driver or the IE driver or the Chrome driver, which then you interact with and run your test. All right. So how did this problem start? What happened was in pursuit of learning and innovation, the developers, the modern web developers have been, you know, using different kinds of UI components as well as frameworks. So within a weekend, there is a new JavaScript framework which is coming in the market, right? There was Android, there is React right now. So on the other hand, the Selenium community is not that strong to compete with such fast-moving front-end frameworks, right? Selenium itself has an API, let's say, to work with the select components. So have you seen a pick list on a web page, right? So ideally it should be an HTML select tag. Selenium in itself has an out-of-the-box select library to deal with that. It has methods to deal with that, like you click on it, you just give the locator of the select tag, you click on it, you can get the size of the list, you can click on an item by value or by index and stuff like that, right? But there have been multiple other new frameworks which have their own versions of pick lists, right? For example, there is a chosen library by jQuery and there is a React select which does not follow the same standard which the select tag has, right? So in that case, there is a problem with the test automation developers, the Selenium developers who write those tests. They don't know what to do because there is no out-of-the-box library by Selenium. So in that case, they do hard coded clicks on first the dropdown and then select by visible text stuff like that, right? And the another thing is that with medium size to large organization, what happens is people are using common components to enable a consistency of UI in their web apps. For example, in Red Hat, we mostly use the pattern fly. Pattern fly is an open source library of UI components which you can use like dropdowns, select boxes, radio boxes, stuff like that. So you can straight away pull that and use in your web applications to maintain a consistency. Let's say you have 20 different web applications in your organization, some payroll applications or maybe any other applications inside your organizations or public facing to maintain that consistency of UI, your brand, you use similar components. So what developers do is they fork some other libraries of the UI components and make some changes and create their own library and then reuse it everywhere in all of these web applications or what they do is they straight away use some existing components like the React Select. And this causes problems. As I said, Selenium does not support a lot of so many web components, right? It's not a community which is moving as fast as different and community. So there is a problem. Let me now show you the... So my colleague who could not come here due to the visa application created this demo app. So these are three different picklists. The first one is jQuery chosen. Again a list of countries. The second one is simple HTML select tank, which is again a list of countries. And third one is a React Select library. So if you are testing an application, if you are a front-end tester or a e2e tester on an application, which is using React Select, then you will probably have to create your own library, UI library, testing library to work with the React Select component. So if I open DevTools, you'll see that the React component is completely different because it's not a select tag. The first validation which Selenium's out-of-the-box select library makes is to check whether the HTML it is dealing with is a select tag. So you cannot use the Selenium Select library here. So you will have to create your own. So our strategy in this case was because we were also using our own component library. The developers had created a component library. So as a QE member, my strategy was to test the component at source. Okay, let's say there is a component library of five picklists, two radio boxes, text boxes, text area, stuff like that. Maybe date pickers, right? Everything you need to build a web application. You have your organization's component library. So what should be the ideal step now is to create a simple web page, a bare-bone web page like this. And feed it with hard-coded JSON data like I have done. It is just a list of countries, right? I don't need to follow business logic here. This is just a test page. So for the library, I created a test page and I write my Selenium library based on this test page. Are you getting my point? Any questions so far? All right. So once I have written my Selenium library for these, then I'll run some tests on it to make sure that at least this thing on the source passes, then different teams which are using these components can use my test library as well instead of inventing the wheel again and again. They can use my test libraries in their test automation frameworks, right? So I'll just show you an example. So these are three tests. Should I make it slightly larger? How about now? All right. So these are three different tests. The first one is the chosen demo for the pick list which uses the jQuery chosen library. Selenium does not provide anything to deal with this chosen pick list. So what did we do? We created a separate chosen library modeled typically on the actual Selenium select library. Okay. So it exposes methods like get options, select by index and select by value. And it depends on you how many methods you want to expose. But I lead these methods to the job. You just have to select, let's say one country from the pick list. And the second one is the react select. Again, there is no Selenium library for react. So we created our own, which is very similar to the chosen library. But there is an existing library for HTML select when a developer uses actual HTML tag to create a pick list. There is a Selenium library. So we did not need to create anything for that. Okay. So I have, if you look at line 25. So I create an instance of the chosen library and select by index four. So whatever option is on index four, it would get selected. And you can also select by visible text or value. So I'll just go ahead and run them. So you can see how it works. Right. So the benefit of doing this is now any other test automation engineer in my organization who is using a react select component who is testing a react select component. And there, there can be multiple react select components in one web app only. Okay. Let's say we have a customer success web app in red hat and it has six different reacts that components. So that person that test automation engineer does not have to create a new pick list library. Now he can reuse this plus since the component is tested at the source itself, there are no chances of the test breakage due to the actual component developers changing something at the back end. Right. If they change something, if you look at this code. So it is searching elements, the list of elements by class by class name option. Let's say tomorrow the developers of the core developers of react change it from option to let's say li right. They can do it right. They are the owners. So if you're not testing at the source itself, it would break all the 20 web applications in your organization, not the web application itself, but their testing frameworks or testing or the test right to avoid that. But we will do is we create a sample page, put the component in it, put some hard coded data in it and test it on source. Then every test automation engineer who is part of the teams working in different web apps in your organization is at least shielded from those breakages. The thing with it testing is that there are multiple chances of breaking right. There is this browser and serenium urgent incompatibility. There are other stuff. There is a lot of other stuff which can break it. So actual component level change, breaking your test is something which you don't know. Right. Any questions so far? All right. See another benefit of testing the component at source is that your test. The purpose of testing is not just test automation. Right. You have to find current cases. You have to break the app stuff like that. Once once breakage of tests, this problem goes out of mind of your QE, then he can focus on probably under different things. Right. All right. Any questions? So I was just, this might be the wrong question to ask, but what is the benefit of this or something like using just testing, you know, like the node package that allows for things like snapshot, snapshot testing and end to end testing on any JavaScript front end framework. I don't think just does end to end testing, you need to have, let's say, let's say you are testing react. Right. For integration tests, you can use just for end to end testing, you still need to use something which has WebDriver.js associated with either night watch or WebDriver.io or the plane out of the box WebDriver.js. So until and unless there is Selenium in it, it won't open the browser and manipulate the DOM. Does that answer your question? Okay. Any other questions? So yeah, I do functional utility testing on the SAP dashboard. So hypothetically for like a code coverage standpoint, how would you be calculating that or anything of that sort through this? Code coverage with front end test is a tricky thing. So there is one tool called Java code coverage. So there is a plugin which you put in your repo and then you run your front end test. So based on which parts you are taking while running your front end test, it gives you some sort of code coverage. That's not something to be very, that's not something which is very reliable and promising to be honest. So code coverage thing is mostly done on the unit test or an integration test level. All right then. Thank you everyone. And just to let you know that this these both this app as well as these libraries. So if if anyone of you is using reactor chosen in the, I know most of the red hat apps use the reactor as well as chosen. The red hat customer portal uses chosen dropdowns. So if you're using any of these, so these things are on GitHub, feel free to use them. I'll probably paste this in paste a link in my presentation for you to check. All right. Thank you.