 Can you hear me? Okay, well, great. So, hello again. Wow, such a big group, 4.15, the last day of the conference, and you are still here, so thank you for going to our presentation. Our topic is called Breaking Down the Barriers, Testing Desktop Apps with Selenium. So, let's start. First, something about us. My name is Michael, and this is Filip. Hi. We are both few engineers, mostly we care about test automation, and generally about continuous deployment, continuous delivery in Avas Software, which is Antiverse company. If you have some question on us, and there won't be time in the end of the presentations, mail us or reach us on the link at the end. What is going to be today about? First, we're gonna do some intro, what we are doing, and then I'll pass the word to Filip. There will be some introduction about what is actually going on, and why we are trying to use Selenium for testing desktop applications, and after that, I will try to do some live demo of that, so we actually see that it's not that hard, it's pretty simple process, and you could run it easily yourself if you have such an application in need of testing, and at the end, just a few last words, how that is actually useful in the whole continuous integration environment. You know, we wanna prove that we are not just talking, that we are doing something, and we wanna show you that it's possible to do it. So, let's start with us company, because thanks to us company, we are here and we are able to tell you how we are using, I'm sorry, Filip, I have to say it's Selenium, I promise to Filip that I will not say Selenium in my presentation, I'm sorry, I said it already. So, we have our software, who knows our software? Wow, great, what are we doing? Antivirus, security, yeah, this is what we are trying to be there. We are antivirus and security company, we are most well known for our Windows antivirus, and who is using antivirus for Windows? And who is using antivirus for Mac? Are you satisfied with it? Did it catch any virus? Yeah, so it's a great, so it works, this piece of work. So, our most famous product is of us antivirus for Windows itself, then we have products for mobile security, we have VPNs, which we call SQLine, we have Cleanup, which is a performance tool to improve the performance of the computer, if you have users, have lots of strange apps installed, so it might clean it. And this is the topic of these days, that the password, we have a password manager, and we are not just only Windows company, we are also running our apps or Android macOS. Generally together, we have about 230 million users, and if you wanna know something about us, just go to our web page. Yesterday, during the lunch, I was talking with one gentleman, and he asked, where is Czech Republic? I don't know, so I said Czechoslovakia, and it was better. And then he asked, how many people are there in Czech Republic? I said 10 million, and he said, but there is 10 million people in only in Bangalore, so we are small. So if you don't know us yet, if you know Germany, so just next to Germany, there's a small statement that's we have. But let's back to our topic here, why we are here. The question, what we were asking when we were trying to test our Windows of us antivirus was how to test, how to write checks for our UI, it looks like this. It's a desktop application, Windows desktop application is not a browser. So we were asking that, what can we do? We tried to automate it, we auto it, didn't succeed. Then we looked more deeply to the UI, we used spy plus plus to look how the MFC object looks in our UI, and then we saw the objects, but then we realized that we don't see the buttons for this, and the reason why we haven't seen is this. When we looked into our UI from a different point of view, we have seen that it's a normal webpage. This is just HTML code as you probably know. And then we saw, okay, so there will be maybe some possibilities how we can do UI testing. But when we look on the antivirus architecture, what do you think, what is the most important part of the architecture in antivirus? Which part of the antivirus is the most important? Scan, yes, right, and the second? Yeah, yeah, no, licensing. Because you need money. So we have engine, which is mostly written in C++, some part in assembler, it's crazy, I'm glad that we don't work with this single part. What we are able to write tests for this part in our QE department, there are some integration tests, we have end-to-end tests in Python using boost framework, but generally, in this part, there is no UI tests are needed, so why to test UI if the UI tests are not needed, no, it's not true. Oh, I forgot that there is this amazing picture there. It just shows the scale of how many configurations of operating systems, we have to test the antivirus, so we are sure that you are secure, because if you release a version and your computer goes blue, then you are in great. Well, that's the same. I talked about the antivirus engine, that's what is not interesting for this conference. What is more interesting is the UI. The UI consists of two frameworks. One is, and the old part is the HTML layout framework being used in all parts of UI, and the new is set framework. HTML layout enables us to represent our UI as a normal web page. It's the old, it's the render of HTML code, and it's based on IE6. Does anyone use IE6 still? No, no, no. Yes, it's some corporate, big banking. Yes, luckily we are not a bank. And with HTML layout, is that a problem that the big parts are represented as normal MFC objects for Windows? Inside these MFC objects, there are these HTML buttons and links and everything you know, and we were totally blind how to reach it yet. We try to use SQL, which is a tool, which is good for testing when you click on the objects based on their representation as a picture, but we were simply, we were not successful. Then we appear, Ceph, which is the shortcut for Chromium Android Framework. Philip is going to talk about it. And with Ceph, we have the new parts of the UI. So right now we are still in the process of continuous transition. As from the old HTML layout application, we are moving to Ceph more and more and more, and in the next year I believe that we will be completely out of HTML and everything will be fine. And this allows to use this magic application, which I am not allowed to say right now. And magic happened. Generally, I have to admit that for us, it used to be that we failed in UI testing. Right now I'm passing the word to Philip, and he will tell you about the success. Thank you, Mikhail. So yeah, we used to fail. So what was our motivation to actually look for a new tool for testing? The UI testing tools are usually very clumsy. There are very inflexible, and that's all based on that. There are actually image-based that when one small thing changes in your UI, you have to rewrite or re-record a majority of your tests, unless you're using some modern tools. So as a result of that, the maintenance costs of those tests are usually pretty high, and that's why they are not usable. So what's the solution? Well, we need a testing tool that can access the base structure of the UI, that can see it as a developer boot, or as you can see a website when you look at its DOM. And furthermore, that would allow us to create a testing framework that we could use that can further lower the maintenance costs of our tests. And it kind of turns out that we already have that in WebRite. We have Selenium. So we tried to look at possibilities of using this wonderful tool with our application, and it kind of turned out that it is possible. So testing desktop applications with Selenium. Yeah, I'm saying, sure, why not, let's do it. And why is this topic important at this age? It's because more desktop applications nowadays are not written using Windows components, but are actually written as a website. So when you have some website code running there, it usually means that you have some browser emulation running in your application that is actually displaying that code, and that's why Selenium might be a good idea to use for testing desktop applications nowadays. So where the magic is? Well, we first, we connect Selenium to the application to be actually able to test it. Then we will be able to access its DOM just as a normal website. And after that, obviously control it, do all the Selenium specific stuff, like clicking elements and finding the elements on the site. And furthermore, we will be able to actually create a Selenium framework. By the way, how many of you have already created some testing framework to help with your tests? Great, that's quite a few. And anybody did this in Python? Well, almost none. I know that Java is the most popular one. So there are this 100 people here, so we have new 100 Selenium frameworks, right? Almost. So, yeah, sorry. There are some prerequisites for our testing. One of them is, as was mentioned, the SEF, which stands for Chromium Embedded Framework. Anybody using that already? Okay, great. So there's a lot of possibilities to do with this wonderful tool. What it does, it is a basically browser engine that provides a desktop application with the capabilities of a normal browser and allows you to render webpages inside your desktop applications. The webpages don't necessarily need to be online. They're usually local because you don't want some loadable components that are online in your desktop applications. That usually seems weird, but you also have this possibility. So if you have some content that you want to have locally stored and in some parts of the application that you want, when timing really matters, that you want to have it fast, you can do that. And when you are implementing, I don't know, a store inside of your application, you can also build that store as a online website and then load it later into your app. So yeah, SEF is a good tool to use, I think. Then for creating the test, when you're doing a test for your website, you usually try to find a way how to find that element on the site. So you're using a debugging console in your browser for that. For a desktop application, you don't have a debugging console, you cannot simply press F12 and display a debugging console. But as it turns out, there are some tools for that. There are some developers tools for SEF that you can actually insert into your application, which will then provide you with the capabilities of debugging console, which will then help you in writing your tests. Then you need Google Chrome in this case because SEF, it's a Chromium-based framework and also the console is based on the Chrome debugging console. So it won't, unfortunately, this won't run in any other browser than Chrome. And last, you, of course, needs the Chrome driver, the Selenium component. So how do you open the debugging console? How do you actually plug it into your application? Well, turns out it's pretty simple. You just need the libraries for that. Then you will select some port that you have available and you will open that port for the console to connect to. Let me actually show you how that works. So here we have a typical Windows computer. It's running Windows 10. We have, I was installed, as you would expect. And how do we look at what this page looks like when we want to look at the DOM? So actually, this one is still written in HTML layout. So let me switch to some that isn't. So for example, here, this page is written in self. I can fire up the browser and I can connect to the application. So I know it's running on port 5555 and it's running on my local host. So when opening the page, I should see the console. I don't. Well, that's because I didn't actually open the port yet. So let's take a step back and look at all the prerequisites. So this is the base folder of your application and that's also where the self libraries are located. So when you look for Libsef, that's the main self library. You see it's there. Based on the version of the Libsef, you can select the version of the tools that you need and also insert them at the same pass that these libraries are. So when I will now look for deaf tools, I see that I have them already copied here. I have the correct version. You just have me trust, please trust me on this. So now I will actually kill my application and what I will do is that I will restart it but I will restart it with some special parameter that actually opens the port for the console to connect to. We have it here, looks the same, which is good because we want to be testing the right UI, the production UI, not some testing version of it. So let me navigate again to some page with that is written in self and let's look at it in Chrome. Let's look at it in Chrome. So now at the, is it visible? Slightly. Here we have the address with the port 5555. It's on our local host and we can see that there is some page that we can open the console for. So let's do just that. And now we see the DOM of our page. We can even do the usual stuff like selecting an element. So let's try to look at this button. We see that it works that we can actually see all the information that we would expect. Okay, let's get back to the presentation. So how do we connect the driver to the application? Well, we need to have the console up and running and connect it to the application and then what we will do, we will not actually connect directly to our application but we will be connecting to the debugging console which as we just saw provides us access to our application. And yeah, we will be able to control the application through the driver, through your console and then to the actual site that is rendered there. And now we can just let Selenium do its job. Okay, how this is done? How do we connect Selenium driver to the debugging console? Well, let's take a look at some code. It's actually a pretty simple code. It's here we have a driver object in our Selenium framework. This is written in Python by the way. And at the beginning we are specifying what the port is that we will be connecting on the address and kind of the mandatory pass to our driver that we will be connecting to. What's happening then? We have some initialization method in our driver object and we will be specifying some options for that driver. We can use the standard Chrome options because it's Chrome based but we need to add some debugger address which is the address of our console that is connected to the application. And then we can just create a new instance of the driver with the appropriate parameters. And this provides us with Selenium driver that is able to execute our commands, execute our script and is connected to the desktop application. Let's take a quick look at another example. So just that you can see how we're using the driver. So this is some simple page object for one of the pages in our UI. And we are doing some waiting here. We are using the driver instance that we saw on the previous slide. And we are just waiting for some element and then locating an element by xpass. So we're actually not doing anything special. From now on it's just a standard Selenium that you are already using for testing your websites. So let's take a look again at a practical example of what's actually going on there. So here we are again at our favorite machine. And we can take a look at the test. So what is actually going on here? We see some invisible, oh, let me, let me, so what we can see here is we have some base class of the test that is actually doing some setup for us. We are preparing the test as a usual unit test is prepared. Then, okay, let me get back to it. Yeah, and then we are doing a setup before each test. So let's run them. Let's look at what is actually going on. Some setup is happening. We're restarting the Avas UI. It's done. It started the UI with the console open, and it ran some sample script. The tests are actually based on some replace of a functionality that is there. So they are more stable. So we don't have to wait for the scan to finish every time. And what it's doing now, it's waiting for the Selenium to connect and then do some quick checks just to see what was actually rendered on the page and if it was rendered based on the data that we served into it. In the second test, this is just an example of some interaction. So you can see that we can not only read what's on the page, but we can also navigate it. And I hope you noticed that this was, in the first example, it was closed. Now we clicked on that row and we actually opened it using Selenium. So let's take a closer look on what was going on. And let's run the tests again, but with some breakpoints involved. Okay. So first there is some setup. Setup happening. Let me minimize this. Is it visible? Great. And we are just doing some, yeah, we are just doing some preparation. We are setting up the environment and we are preparing the replay that will then be tested. So let's move to the next point. Here's the correct button. So now we should see it start up the UI again. We should see it run the replay. We should see it prepare the environment and it will stop right before connecting, right before connecting the driver. Okay. So now we can see that we're actually in the, oh, it's small again, let me. So now we can see that we are actually in the driver class and we are in the initialization method of the driver and what is going on is that we are right before creating the instance of the driver. So when this is executed, the Chrome driver, its instance will be connected to our console. It will use some, it will use the defined options, which are basically the same of what we saw on the slides. So let's move forward. And let's see what will be happening next. So we connected to the UI and we did some quick checks as in the first test. And right now we're again waiting for the connection. And we just cleaned up after the test and what is going on right now is we are doing the preparation part and I'm sorry, I seem to have misclicked the button, yeah. So let's actually stop this run. Let's even stop this, stop this session. Okay, it might work. Great, so that's the button that I wanted to click. I'll just give it a couple seconds before it is ready and we will take a look at the Selenium code that will be then executed by the driver. So from here, we will get to the, right point and great. We need to get to the second test that we will be examining. So here we are ready for the second test. Again, with the driver instance ready to be initialized. Let's take a step ahead. And now you can see that we're actually in the test class. We're inside some test and we're inside some test that says just open vulnerability, which is the red line that we're trying to click on. So let's dive into it on what's happening. Now it's with them. So now at this point, we move to the page object and here we have implemented a standard Selenium function, which calls the instance of our driver. It tries to find some element by its class name. And then what it does at the end is that it clicks on that element. So if we take a look at the UI, how it looks now, we can see that everything is closed in its original state. And if we move one step ahead, we should see that the UI is actually now opened and that our Selenium code navigates through the console to our application and executed there as on a usual website. So that would be all for the demo. And let's go back to the presentation. Well, a few final words from me. Why I think that this is cool is because it's not only usable for self-built desktop applications. There are many other frameworks that are nowadays spreading and that can be used to actually execute and render website-like code inside desktop application. And all you need to do is to find the correct driver. If there is such available that works for that framework and you can connect to it using the debugging console and you can start using Selenium for testing desktop applications. Now let me pass the word back to Michael. Thank you. So no more browsers, but Chrome console is going to be used now for Selenium testing. Who's in? Looks like almost everyone, okay. I promise to prove you that we are not just talking about this, but we are also using it. I'm asking myself question, how often run we the test? Let me also ask you, how often do you run your tests? Several times per day. So that's the same for us. We run our tests daily and often. We have three levels of tests. The first level are the shortest, are the most reliable tests would we have. They should tell us that if we have a new build of our antivirus, it won't break the computer. Then we have medium set of tests, which are telling that the basic functionality of our last works. And then we have a long suit of tests which tell us that all the components works in a proper way. And actually this is where our URL tests are running. In the testing, we are using this circle approach that after build, we deploy our last to our testing environment and do the testing. So we are still not in that phase yet, but we would like to be that, almost after each commit, have a new build and have everything tested. To be able to do this, we have a huge infrastructure. The core of this infrastructure is Jenkins, which is the test executor, which is running all the tests on all the operating systems. We have a Linux server farm, which is using DBV and there is a virtual box with all the operating systems. And with these pre-tools, we are running this matrix, which allow us to cover the most used operating systems. The key part about this is that we are using the same infrastructure as we use for our non-UI tests. And we are now able to reuse it for our UI tests using Selenium. And this brings me to the last slide. Do you have some questions? Can we have a microphone please? Is the set framework, does it work on all the Oasis? Or is it only for Windows? In our case, we are using it only for Windows, and as far as some aware, it should be multi-platform. Yeah, in my case, we do have the same kind of publication where we have the CEF in a Windows application. But the problem in our case is, in order to get into that page, we have to log in, we have to pass through the login page. But the login page is not built on top of CEF. So somehow we have to handle with some other tools. So do you face the same kind of issues in your case? I mean, where certain pages are built on top of CEF and some other pages are built on top of .NET or something. Is there any way to overcome these kinds of sluggings? So if I understand it correctly, you have similar application, but the first login step is written in a different framework. Yeah, some sort of .NET framework. Yeah, so we had some success in a SQL application. So try this one, and it might help in your case. What actually might be the solution here is to work more closely with your developers. And if they would be able to provide you with some API access to your application that you can use to navigate the application, you can do the first step using that API. In fact, we are also doing this in our tests to actually limit the interaction of Selenium with UI in some cases. When we really want to be sure that that action will happen every time, regardless of what's rendered. So when I showed the demo and the test was started and the environment was prepared, it didn't use Selenium at all. It didn't click on any run test button or anything. It just used some API call in the background and after that it plugged in the Selenium. So that might be solution to your problem. This is kind of a good tip from Philip that everything what we do, we also consolidate with developers and we ask them to help us, like for example to open the ports to be able to log in to console. Yeah, and do you have access to the source code that you have, the code snippet that you have shown to us as a demo? I don't. I mean, the code that you have shown to us as a demo, do you have access? Can we see that? Access to the source code. If it's somewhere available. It is not, but definitely the slides will be and they contain the important parts. Okay, good. Thank you. I'll just write to Philip. Any other questions? Actually, before we pass the mic, I might have one to answer. Someone asked us yesterday if this is usable also with Electron and as it turns out it is. So not only set, but also Electron is Chromium based. So you can just the same use a Chrome driver and you can build your own framework. But furthermore, there is actually some framework already written. It is called Spectron and it is a testing framework based on Selenium for Electron. So yeah, Electron might be also the way other than set to go. Yeah, hello. I never tried Selenium with desktop but the question is in mind. Mind is, is every desktop application contain HTML in background? So, sorry, your question is, how will, what percentage of desktop application would this be useful for? Yeah, yeah. I don't have the exact numbers. When you, but the general idea is when you would try this approach on some legacy application, you would certainly fail because those applications are written using Windows components or the native components of NaOS. So nowadays, the applications that are actually using the more web-like UI approach, all of those should be eligible. All of those, there are actually, there are just two major frameworks for that, that's Electron and that's SEP and both of these, on both of these, this approach is applicable. It really depends on a framework, yeah. In the past, when there was HTML layout, it was no go for us. Then we switched to another framework and now, right now, we are able to test it. So it depends on the architecture of the system. Okay, fine. When you have a new build available, how do you deploy it to the X number of VMs that you have? Do you have a silent installation process or you're using a CM tool or something? Yes, we have a silent installation process and we have another framework for installing and managing with the virtual machines written. So, we have a written code. We're really grateful for that. There was a wonderful talk about this morning about merging UI and operations. It's already happened in our company. So we have a wonderful two guys from QAOps and they're preparing the infrastructure and they're actually taking care of the installers. So even before you get to your tests, what happens in the setup, what happens in the Jenkins runner is that they will fire up the VM, install all the packages that you specify, which can also include your application and will serve you a environment ready for testing. And after that, when you're done with your test, they will also tear down the VM or make it lately available if there are some issues found in the test. If you discover some bug, you can then manually go to that VM, fire it up again and start investigating if needed. So yeah, QAOps are really important, as was mentioned on the talk. Like this part was mentioned in the morning that infrastructure has to be reliable. Yes, it has to be very reliable because then it helps you to focus on testing, not just on fixing infrastructure. Thank you. Can we repeat it to Mike, because we haven't heard yet. For the silent installation, I think we can use the Vagrant tool also. So again, it is an open source which create VMs in VirtualBox, Hyper-V and all. So it has a boxes which you can simply call and it will silently install the virtual machine and then it is ready to use. So you can try that. Okay, great tool for somebody who doesn't have QAOps and wants to try it in a quick way, I think. Thank you for that. It seems that this was our last question. Again, if you have any follow-up questions, don't hesitate to contact us, email us, write us on LinkedIn, whatever you need and we will be happy to help. So thank you. Thank you for bearing with us on one of the last presentations at this conference and yeah, enjoy tomorrow, enjoy the workshops. Thank you. Thank you. Thank you.