 Let me introduce myself. I'm Diego. Maybe some of you know me, maybe some of you don't. I am a core member of the Saladin project. I do a bit of everything around the project. And also I am working at Source Labs in the open source team, which is a huge privilege because I can spend quite some time working in open source. What are we going to be looking at today? So my intention here is to give you an overview of how the web has evolved in a very brief way. And also I want to share with you how testing has evolved along that. Having said that, I will give you a quick demo about Selenium, but before saying how is Selenium fitting in today's testing with all the new frameworks, with all the new web technologies. And then a bit of sharing with you what the Saladin project will be doing soon in the next couple of months. So something that I'd like to highlight in every single talk I do about Selenium is that this is an extremely open and welcoming project. So Selenium is completely free setting speech. We have an open governance, which means that everyone can see how we run the project and everyone is allowed to join the project by following very simple guidelines. We are based on standards and that's why we have, for example, four huge companies supporting the web drivers standards. But also we have companies like Wikimedia or countless companies who are interested in supporting this standard. And that means that when we want to make changes and plan the future for web automation, we have the support of companies like Mozilla, Apple, Google and Microsoft, who are the ones that can actually make the changes in the browsers. Some of those examples are the bidirectional protocol, which I will talk beautifully a bit later. And I will also talk about the Shadow DOM, something that has been done recently, a huge effort by Gem Evans to specify how it works. And then thanks to these companies and the W3C group, we are actually able to provide those things that work cross-browser. And super important to highlight is that Selenium has been made by and for the community. So there is no company behind Selenium, there is no commercial interest, which is quite different as the competitor tools. So let's get started into the topic that we want to talk about today. So web testing and the evolution of these two things, the web and testing. So if we think about many years ago, talking in web terms, so let's say 15, 20 years ago, at the beginning we had a bunch of static and limited websites, right? So the main intention of these websites was to provide content. And in some cases it was some e-commerce, perhaps the first versions of Amazon, you could say that. But in the end, the idea was that the user could receive information and there was not much interaction with the user, right? There was a lot of server-side rendering, which means that everything was being compiled and sent by the server and being rendered to you, the client, so the browser that you had was not that smart. And actually, that was one of the issues where you were, for example, filling out a form with 10 fields and maybe you made a mistake in the last field that was supposed to be, I don't know, an email address or whatever. And then you were sending that information to the server. The server was actually checking the validity of the information and then it was sending you back an error with all the fields sent to you, right? So that was very annoying because most of the work was being done on the server side. Back then, most of the testing was focused on desktop applications and web was not really something that people were paying a lot of attention in terms of testing and usability. And that's why people who were interested in testing were spending their efforts doing manual and exploratory testing approaches. The web evolved a bit, right? And we started to focus a bit more in applications that were interactive. So you were allowed to create content, very simple, which could be in the shape of posting comments in a blog post or somewhere else. You could have also dynamic HTML, so you could have a website that was changing without having to go to the server to make changes, right? And that was the client-side rendering. That's when we started having JavaScript to be more popular, where we started to have CSS to make things look much nicer. And that was the first presentation or the first presence of JQuery. So you could do things locally, like you could have managed events and you could use Ajax and so on. Those were the times when we started to see things like UTP that today is called UTF. And the first versions of Selenium. This Selenium 1.0 that was working in a very interesting way, which was basically that you were invading the browser and embedding a lot of JavaScript into it, which is much likely how Cypress worked, for example, nowadays with this approach that was used many years ago. Then we moved a bit forward and people started to pay more attention to the web applications. They started to think about how can we structure these applications in a more elegant and maintainable way. That's when people started talking about the MVC model, the model view controller model, and we started talking about APIs, so backend services that could serve information to these frontends. And then the point was that we were actually starting to decouple where the logic was going to live. Not everything had to live in the frontend. These monoliths, we could have things that could be divided like frontend, something in the middle, and maybe some backend services and so on. We started to see things like Ember, like Angular, and then we moved to this component type of architecture that is available in modern frameworks like React or View. If you go and check any tutorial about React and View, that's the keyword, right? Components. That's how you can start creating modules in your web application, and that is actually giving you many, many possibilities of reusing components and bringing these applications in a more simple way. What is interesting about this approach when you have an application that is using the MVC model but you have APIs, when you have components, is that you can now actually test these applications on different levels. You don't have a monolith anymore. You don't have a single point of entrance for the application. And now you have applications that offer different paths for testing. And in conclusion, what we can think about this is that end-to-end testing is not the only option to test an application. Going a bit deeper into that statement, what is the meaning of that? If you are using one single tool to test your complete application these days, this is usually not a good approach because some people want to do API testing with a tool that is mainly used for browser testing, right? And this ends up happening as you are launching a browser to do an API test. This sometimes is not the most effective approach and that's why you can start to have different approaches like using an API testing tool to focus on API tests. For example, if you want to test web components and you actually need to open a browser to test web components, that's a bit inefficient because you can actually use different tools to test web components. Like React comes with tools that are ready for that. And to summarize this point, what I'm trying to say is that today in the modern web testing world you need a strategy that is successful because it relies on different approaches. You can use, for example, an approach that is quick giving you feedback through functional tests and when I say functional tests you don't need to use an end-to-end testing tool. For example, you can do component and end-to-end testing. And for example, when you are sure that the functional layer is working well, then you can start adding things like visual, you can do performance, et cetera, et cetera. Maybe this is easier to understand with an example. And that example will help us to understand how Selenium is placed in today's testing. For Selenium 4, we have built a new UI for the Selenium grid. And we are using React for this frontend. And if you make a pause here and you look at the UI you could think about at least three different use cases that you would like to test in this application that should always pass. For example, one is that if you register a new node you want to see the node registered in the UI. If, for example, you start a session in the Selenium grid you would like to see the session running when you click on the tab about sessions, for example. And I don't know, when you actually start a node and you kill the node you want to see that the node is actually being moved away from the UI. So there are different use cases that you want to test and they should always work. But there are also many, many other use cases that you would like to test but maybe it's not really necessary to open a browser. For example, if you register a node and it's a Linux node, maybe you can do assertions in the type of, okay, the node is there and it's actually Linux and it has Firefox browser so you could start going very into the detail about asserting small things in the UI. And that means if you use an approach where you're using only end-to-end tools to test this user interface application then you could end up having easily, I don't know, 50, 60, 70 tests with Selenium. And the question I want to ask you when talking about different levels of testing is I don't know if you have had a look at the Selenium repository but we use an interesting approach regarding testing this application. So we have the presentation layer, right, which is what you just saw. We have the logic that is split between something in the UI with React and some parts in the API that we use GraphQL and we have the service which is the API and as I said it uses GraphQL. Then what happens there is that we have API tests, we have unit tests for each one of the parts and I'm going to start asking questions but I know that you cannot reply if you want to reply in the chat in the comments I'm just going to start asking. How many unit tests and API tests do you think we have to cover all these use cases? I'm going to say one, two, three, four, five. I'm going to give the answer and I was wrong. I forgot to tell you something else. Sorry, I went ahead too fast. So to give you context if you want to test all these three layers you could use an end-to-end tool. You can use Selenium to actually test every single thing in this application but there are also approaches that you could have a mock and this could mock out your unit tests and your API tests and this means that you could use also you could do integration tests and you could test the UI without having an API running. That is incredibly helpful because you don't need to wait for the backend team to be ready with the application ready to be tested. For these approaches Selenium is a good choice because then you can actually do the proper testing, right? Then you have a different layer which is components. React offers you a way to test components in a very efficient and very quickly way. And for that, in the Selenium project we're using Jest and Test Library. Now the question. We have around 150 unit and API tests combined for all this functionality. On the integration lever which is using components to test the different use cases inside the UI we have 30 tests for that and they take about 10 to 12 seconds to test everything. And on the top level which is the slowest type of test and it's an end-to-end test that opens a browser and renders the page and uses the network extensively we have only three tests. And that's the approach that we're taking today and that's the approach I would like to recommend you to have a look to test your applications. Don't use a single application. Don't use a single tool to test your applications because there are different approaches to test these things. I'm going to have a quick demo and it's going to be extremely quick because I just noticed that I explained and went too much into detail. So what I'm going to do, I'm going to tell you that we have a web application and I'm going to show it very, very quickly here. And this application has an authentication it's a visual to do app and you can add items and you can, like, when you add an item it will show you an image related to the item so this is our web application for testing. Basic authentication, I will skip that demo because you will see it implicit in the other demo so how you can go through basic authentication. The Shadow DOM application part I will skip it as well because it's something very similar to the find element locator that we traditionally use but don't worry that all the code examples are in GitHub so I will share the repository in a moment, okay? I will talk about this one which is the interesting one, the network interception so I was sharing with you a moment ago the approach where you could actually mock the API and run tests in your UI without having an API running so here is the example when you add an item, for example, here this will add an item through an API and will render an image taken from Unsplash so what I will do, I will run a test that will replace this image it will mock the API from Unsplash and will actually show you how it can mock responses from different places I'm going to go to my IDE and I'm just going to run this test very, very quickly so this is a test that will replace the image that will be shown with a source bot so you will see what that is I'm going to add an item that is called BuyRise so you should see an image of Rice and instead of that you will see a Christmas image and what I'm trying to show with this example is that the backend doesn't need to be running doesn't need to be running because you can mock the responses from the application and that's extremely, extremely important because you don't need to have the whole stack running to have a proper assertion to your application and I'm going to run one last example because it's super nice to show that you can replace images but what about the responses, right? so I'm going to run an example that says an item will be clean the bathroom and the mocked response will be I just want to go to the park and I click on Add Item but the mocked response will actually show in the UI that you are able to do something else and this means that you don't need the API running you can do something else instead of, yeah, like having all your test stack running okay, I have a few like one, two minutes left and what I'm going to do is I'm going to share with you what is coming up in Selenium one thing that we're starting to work in terms of like writing a document and specifying how things will work is a browser manager and a browser manager what we'll do it will download all the browser drivers for you and if you don't have the browser installed it will also download the browser for you also the next thing we're doing is to bring the web driver community together so there are many projects built around Selenium and what we're going to do is we're going to bring them together to a single place so you have a better optic about the different options that you can use in Selenium so you can have a framework that has automatic waiting a framework that helps you to extract I don't know the hard file and so on and the message here is that when you think about web driver it's much more than Selenium so you have the Selenium project right? but you have tons of projects built around and this is the true web driver community so we are not just Selenium a single project we are over 10, 15, 20 projects helping you all as a community I will share more details about that in a future talk so if you're interested about this please come to the chat on the Selenium website and you will be directed to the Slack channel but also you can go to the repositories I was sharing a moment ago and I could put them in the chat so you can have access to the examples and to the application I was sharing as well I just want to thank you all for being here Thanks for the wonderful talk, Thiago