 So in that case, your line of code in your console will be just one line, which is the execute for the inspect break. I did a video on debugging in WebDriver.io using the VS Code debugging. So if you're interested, I post that in chat. Oh, thank you. Anything for WebDriver.io? I mean, sorry, for WebStar. It's definitely for WebDriver.io. No, not for WebStorm. Okay. Cool. So I started recording the session just in case we want to upload this to YouTube or not, but recording, I think, makes sense. So I don't have much of an agenda. Thanks, everyone, for joining and for the second contributor meeting. I think we had one last year at some time in the summer. I'm not sure with a couple of other people, but now I thought doing the call-up summit would be a great time to just meet and have a chat about WebDriver. And I would say before we start, let's do a round of introduction, because I'm not sure if everyone knows the other person and tell who you are and where you contributed. I will start. I'm Christian, working at Sausage and started contributing a while ago to WebDriver.io and had my fingers almost everywhere, unfortunately. So, yeah, I give it up to Xiu. Oh, yeah. So my name is Xiu. Working in the Bay Area, US. Now right now I'm working at the biotech company. So got exposed to WebDriver.io back in 2014. Then make a little bit of contribution, right? Christian, not too much. But I would say I have a lot of feedback, because I'm kind of a field engineer, so I work in the real testing. So I had a lot of feedback, you know, how WebDriver is being used. So, you know, I've been giving, I think that's the main part I've been giving back to the team that, you know, how should we, like certain features, you know, it's most often used in the field, rather than you just, you know, for the sake of a new feature, like theoretically is, you know, it's useful, just in your imagination, rather than, you know, you're working on a real problem. That's why you get the, that's where you get the first-hand experience. I think that that's it. Just pass it to someone else. Maybe, Arvind? Yeah, sure. Hi guys, I'm Arvind. I'm from the Netherlands. I work for a tech company called The Testers. I've been working with WebDriver.io for about, I'd say five years now. And part of the steering committee worked my way up from, like, I think it's been around three years now since I've been contributing actively. And I'll pass it on to Wim. Hey, well, I'm Wim. Wim Sellas. Living in the Netherlands. Work at Sales Labs. A colleague of Christian. And contributed to, or started using WebDriver.io, I think, three years ago for a native app, a React Native app project. Started helping out with answering questions on Gitter. Did some pool requests and created my own plugins for WebDriver.io and got a lot of support from all you guys. So thanks for that. Okay, Wouter? Hi, my name is Wouter. I'm also living in the Netherlands. So, hi. I worked at a big web agency in the Netherlands. And used Cucumber over there and then integrated it with WebDriver.io. So I contributed a lot to the Cucumber boilerplate project. And nowadays I work at a tech company that's called Sorgdamein, working for Dutch Healthcare. And we used Protector before, but we were not really happy about that. So we're now also switching to testing Angular with WebDriver.io. So next, it's called Clamping. Kevin, but my screen name for some reason does Clamping because I can't change it because it's Zoom. Kevin Lamping, I have been working with WebDriver.io for five years maybe. I originally got into it because I was interested in visual regression testing. And there was a tool called WebDriver CSS Wayback Win. And then that got me into testing, just functional testing. And yeah, I really enjoyed it and wanted to... I've been working a lot on the documentation side, creating... I created a course way back then, which needs an update. Created a... We're finishing a book on WebDriver.io right now. And I've done a lot of videos on it as well. So kind of less on the code commit side, more on the documentation side. But still really enjoy it. Let's go with Divi. I said that right. Divi, you're muted if you're speaking right now. Otherwise, Mikolai, can you go ahead? Yeah, hello. So yeah, my name is Mikolai. I started working with WebDriver.io, I guess like two years ago, or maybe two and a half years ago. I was looking for some framework that would simplify browser setup and would allow to run tests in parallel, like really easy. And it was a good match, especially after Java frameworks. I did contribute it to WebDriver. Lots of bugs fixes mostly, I guess. Also developed expect for driver.io library. I'm also part of technical steering committee. WebDriver.io. I'm originally from Ukraine, but currently in Spain. I'm going to move to the Netherlands. So we have lots of people in the Netherlands now. Yeah. And well, I used to work as a quality assurance engineer or software developer in test. But for the last couple of months, I'm working as a developer, not just developer, in some consulting company. So yeah, that's pretty much for me. Guys who want to be next. Maybe Olga? Thanks, Erwin. Yeah, I'm Olga. I live in the Boston area in the US. I work for a company called InterSystems. It's primarily, well, historically a database platform for health care, but it's now doing other things too. And I've been doing, I've only used WebDriver.io for about three years, but I've been doing testing and test automation since 2000 to date myself. And as far as contributions, I just recently have started answering a lot of questions on the Gitter channel. Just because I realized it could be helpful there. And, you know, I've learned, learned a lot from there as well. And I guess I only have two code commits, one with, with, with Christian's help with the first ever Web Office Hours inauguration session for, and then for some cucumber hook changes and another one, actually with Erwin's help for some documentation changes for a TypeScript setup. And I think I'm going to do one more for, for as minor change to the, to the cucumber boiler plate project Babel setup, which is missing something. And that's it. I might have out, I don't know who hasn't gone yet. I think the only one is for hook. Go for it. I think we cannot hear you if you're speaking. All right. That's giving us some time. You guys already can think about what we want to talk about. I have something that I want to go over the initiatives that we're clearly on the way that are currently on the way TypeScript support and the network primitives. And then, you know, we can talk about some features ideas, what we want to implement in the future and how we can make contributing easier moving forward. And yeah, anything else? There we go. You're muted still. Soon sucks really. Anyway, my name is Barry or Baruch, whichever one you want. I, I work for a video game company here. So senior engineer. I must admit that I've never used web browser at your professional. I have used other tools like this cafe and that sauce labs when I worked there before. Um, but yeah, anyway, my first contribution, I guess my biggest contribution to a brother I was the ability to select react elements with the, I guess with the name and stuff like that filtering by props and states and whatnot. I've also done some changes to the CLI. And I think that's the most most used to allow for the help tags to be individual to each command. Um, yeah, I guess it's pretty much the introduction. Cool. Um, yeah, let's, uh, does anyone has something he wants to bring in? Um, what we can start talking about. Otherwise we would go over the initiatives. Maybe the, um, maybe the idea about changing the driver setup, maybe that's something to discuss. Uh, which driver setup. Like the way that we handle, uh, the current driver setup when we use selenium standalone versus the, um, the direct drivers, basically, uh, where we can use, for example, the, uh, that driver manager or a own implementation and stuff like that. Um, uh, is there, is there a specific ticket to that? Or is this just an idea? Well, this is just something that we discussed one time. Um, is it something in our roadmap, like manage drivers automatically or, uh, there is a, there is a project for it. Um, we find it auto driver setup. Yeah. Yeah, that would be cool. Um, I was looking into the web driver manager. Um, but that is currently maintained by the Google, by the Angular team or not really maintained. They haven't done anything there. And I wanted to make this a little bit more simpler using, uh, a tool and MPM package that automatically downloads binaries for you based on your system. And that would make the tool, downloading a driver and start the drivers super simple. Um, I wanted to reach out to that team, but I haven't done that yet because I have no, I have other priorities right now. Um, by the way guys, do you think we need it at all? I mean that, um, from the tools protocol is developing like rapidly and can be a complete replacement for a driver protocol. So we don't need to manage actually any drivers. Yeah, that's true. Um, I think the ultimate plan and, um, I participated the first, um, web driver working group as meetings where we were talking about the new web driver protocol, uh, which will pretty much be similar to what Chrome death tools is right now with, uh, difference that you can opt into the death tools. Uh, so you still create the web driver session as usual, but then it allows you to connect to a socket. Um, if you, if you want to, uh, so it can be, it can be still a web driver session, but at the same time the death tools session. Um, and I'm, I'm pretty sure the fact that you need a driver will continue, uh, but you're right that the current death tools protocol works really well in, in Edge and Chromium and Chrome. Um, and will be soon be supported for Firefox stable. It's going to be only supported Firefox nightly. Um, so the Firefox team is working on that as well to make this somehow compliant. Uh, so pop it here, can be run on Firefox. I guess that would be ultimately a nice, nice thing. Um, which makes, you know, me think that this is not the highest priority for me to get this right, to be honest. All right, cool. What do you think is, uh, one of the most important things we need to work on? Well, of course, except of network primitives and UI runner, which everyone talks about. What do you guys think? The UI part, are you guys talking about the GUI test runner? Yeah. Yeah. Okay. Yeah. I really think we should go, go there like sooner. Also, I have a question. So I talked with the Cypress people. Sorry guys, I'm using Cypress. Now, but, um, so, so they told me they were using Chrome debugging protocol. I, I'm not sure that's the same as the dev tools protocol. Is that the same? Yeah. Yeah. So I think they, they told me they, they, uh, also, um, the challenge of, uh, for example, the upload, uh, or something, some feature, the browser feature is, is not, whenever it's not a native, um, browser event, that's where, um, it's hard for the, or it's challenging for them to implement. Um, so, uh, I think probably same thing applied, applied to us as well. Yeah. I could see that they move ultimately to Chrome dev tools because right now they still have, they still trigger the automation with basic JavaScript on the application on the test. I think so. And they are moving away from that to be on Chrome dev tools only, uh, which allows them to use Firefox and Edge and some other of the other browsers, but they will never, they will never be able to automate Safari or other browser or mobile browsers that will never be possible. Or, well, they say they put it on their roadmap, but I, I have doubts that this will happen anytime soon. Do you have any reference for that, for them using the DevTools protocol? Because last time when I said it, I couldn't find the reference that I got it from. Yeah. Um, I assume this is kind of their secret, like trade secrets. So, uh, I think, officially, I haven't seen anywhere. They mentioned that and they probably, they probably don't want to admit they using puppeteer as well. Probably. It's not a secret. Yeah. We're working with our, you know, the native browser, a comium protocol or something. Like, yeah. But, uh, I think in, in general, um, um, I would think, um, the browser compatibility, I think it's as less, it's a less value to any framework right now. I think it's just eventually, I think it was just like, all the browser wonders kind of, you know, merge or like it be unified to under, I don't know, premium, premium or, or anything, or a play, play, uh, you mentioned the play, play, play, right? Yeah. Yeah. So I think instead of spending our energy engineering, you know, um, efforts working on, make it better, I'll support all the vendors on the earth. I think there would be more value to, you know, adding more features, you know, make, let's say, for example, make the upload, make the download, the building, you know, that the more you have a building features, all the box working, that's why I might spend using separate. They have a lot of things just like working out of box. No configuration required, you know, so it's, it's super free, beneficial for the user. So I think that that's the direction I would go, you know. Yeah, makes sense. Um, uh, definitely proposal testing becomes less important these days. And, uh, uh, that's why, you know, focusing on Chrome DevTools features and built them in, like built them into the framework, uh, makes sense, which is why, you know, I started this initiative to, uh, have this network primitives, which I would like to go over, uh, bits. Uh, let's see. So before you get, right before you get into that, I kind of want to second that when the past two years, I've written a ton of tests for Chrome. I don't know how many, like I could count on my hand. So many times I've run it in Firefox or IE. We just never get to that point where we're, we have a test, um, case, um, that we're like, okay, we've got all the test cases that we want written. Now let's check it in different browsers. Um, and the overhead of, of running your tests in multiple browsers and maintaining that is, um, something that I've struggled in the past just because browsers sometimes supports one thing and sometimes support something else for some reason. And, um, so I've kind of shied away from, um, doing multiple browser support because I find it's more valuable just to have more tests that run on a single browser than fewer tests that run on multiple browsers. Uh, yeah. So I just wanted to throw my thoughts out there on that, but obviously anybody's free to disagree and come up with other reasons why, because I can see other reasons. Well, yeah, I would agree that these days it's more important. However, for example, I worked in a company, uh, like a year or a year and a half ago as they still, uh, have, uh, uh, requirements to support AE 11 and it's, um, and it's super, super important. Well, uh, I dunno, uh, about, um, like difficulties in terms of that, but, um, I guess I spent like 2% of time to support AE 11 and Firefix, so it was not a problem for me at all. just added some like hacks because we had like 3000 tests and all of them were working in Firefox, IE11, Chrome. Yeah. And I want to say I don't want to drop support for browser, I think for multiple browsers. I think that's a really big selling point right now. When people are comparing WebDriver.io and Cypress or WebDriver.io and another tool that only does one browser or like PlayWrite, you can say, yeah, we do support multiple browsers. I think that's a big selling point. I just don't think that it's a super, like I just don't think that it's something that I would personally want to focus on. I mean, just as a user, I mean, I also work in a company where, yeah, we're expected to test on the browsers that we support. So, and I found I do run into issues on lists you know, on IE11 or on Firefox that are not necessarily seen across all browsers. So, yeah, I mean, I think it would definitely not just as a selling point, I think more robust support. And I'm not saying these are all WebDriver.io issues. They might be underlying WebDriver issues or Driver issues, but yeah, I guess just a vote for, I think, cross browser attention is good. Yeah, yeah, I totally agree with that. And if you would also look at the the people that are in this room now are pretty smart, know how to do coding, to do proper coding and to figure out workarounds. But I think the majority of the people that are using WebDriver.io don't have the automation skills that people in this room have, making it pretty harder for them to find a workaround. So, I think a little bit of focus on that part might still be very important to support them because it's, like you all said, it's still something that companies want support on. The only thing we might kind of like might be able to promote more is the thing that you also mentioned, Kevin, is like having more tests, for example, on one browser and just maybe do one or two happier error flows on the rest of the browsers instead of running the full set. I think if we can kind of like promote that message more, it would remove a lot of difficulties on IE 11 or maybe on older versions of Safari to get everything working. That's an interesting idea. That's one thing that I did in a set of tests was I had a tag in my test name and it would only, it would either skip the tests on when it had that tag in that browser or it would only run in that browser and that was really helpful. There was something to do with browser execute with getting the form field input and on email address you can't do it in one browser but you can do it in another. I think maybe Firefox doesn't allow you to get the values from a text input that has a type of email but in Chrome you can and it could be reversed but yeah, I had a something in a config file that would be interesting to see formalized. I think that would be helpful personally and I do appreciate you all's feedback on the need for cross browser testing because obviously I'm just one in like one single type of user but you know if everybody else is finding this very essential then yeah, let's do it. Yeah and if I can add something to that also the focusing on the test so enabling, disabling certain tests also really helps in that process. So not only for the specific browser but also just running only one single spec or one single test. So before we, yeah, I want to get to both points. Ben, where you said something like we should better focus on the non-developers that have not the best automation skills. Do you have any particular suggestions on that or where would you, where would you start then? Well, I guess with what was already mentioned is with UI configurator and with UI runner. I guess it should help people a lot. For example, I don't know about if Cypress really has some UI configurator. I guess it's kind of limited but for example when it was developing some website in Vue.js for example they had really great configurator and it saved me like lots of times when I need to install some package or even bootstrapping project or configuring it in whatever way I need. So it's going to be something that really should help users. I guess for example like just have some UI layout where I can check that I want to run tests in Firefox, in Chrome or in Appium and if in Appium then okay again bootstrap project so I can easily start my tests like straight away with desired configuration in whatever framework I need and so on and so on. I guess it's going to be helpful. I think that will remove one part of the challenge that people have. Kind of like the configuration is the first part but I think the second challenge that people have is kind of like just having the proper skills to write something in JavaScript but also being able to to figure out I've got a page it has several components. How can I like code this in a proper way so I can be use a lot of my stuff doing a simple abstraction that kind of stuff and that's not only something for JavaScript that's also something that we see at least with customers who are using Java or Python or Ruby so it's also the animation skills slash coding skills itself. I used to just think in IDE that you know where you can pick elements from the website things like that would help. I have some sort of an idea we can do. I don't know if you can hear me. I think I discussed this with you before Hans question that it was essentially like you can have like a Chrome plugin that you can do like record and then you record some like you select some sort of input and you do some sort of test against that and then just renders a code a file we show the testing code so essentially you don't have to code the test you essentially just recording your screen the first iteration of the test like test that you want to whatever you want to test and then just extract that into a file that you use upload and then the user doesn't really need to know any coding just uses the tool. All tools that have tried is a field I think right? I don't know if anyone has tried it to be honest. Yeah there's been many. I mean as yeah I guess the original example my people are probably familiar with is Selenium itself had the Selenium IDE Selenium 1.0 which did that and I mean I think the general consent you know not to say that it's a bad idea but as a general consensus that was that was not seen as a a really good thing to encourage people to use because it really discouraged having a reusable modular framework just because the way it was implemented it did it did sort of do a linear spaghetti code recording I mean and there I know there are tools that try to do something more sophisticated with that and there's one I don't know if you guys are familiar it's called um it's called excel excel queue or something and um and it does it tries to sort of automate the process where you're selecting things and but it creates this universe of pages and sort of reusable modules and like autocomplete steps sort of sort of like cucumber it sort of mimics a really modular pretty modular framework where you have page objects and on top of that like business services so I mean yeah like you like you probably haven't mind since you mentioned there when people have tried so yeah it's not a bad idea but they're bad I think they're not constructive ways to implement it if it's done in a in a very linear way um I think something to improve here when thinking about the setup and the reusability is we have a CLI tool where we can run uh the install commands but our documentation never actually uses this example at all so people often forget to add a reporter to the reporter list or service to the service list stuff like that I think if we can update our documentation to include this example this command everywhere it would be a lot easier for them to just say okay I install this and I don't need to worry about anything at all it will be smooth so to say and also the um the import examples that we have no no new user is going to know that this is a battle example and they will they all struggle with getting started because yeah it says my import is not working why so I've seen this question a lot combined uh if we want to ease the the transition for new users I would certainly update to those two things and then I would start looking in all the other things that were just mentioned to be honest yeah this CLI install feature is definitely an easy first step that we could do and um I wonder if we could make it simple so that you know when you add a reporter it figures out which options the reporter has maybe the reporter has questions that you want to get asked for and it couldn't add that to it the only challenge I see with that is uh which we haven't figured out yet if you know usually it modifies the wdl config but what if you have like a staging config or like a different name for that config um then it makes it difficult to modify the code so that it it only changes the reporter section um I see what I mean if you have a different name like if you if you you know you have if I have like a common wdl config and then the config for for running things on source labs versus one config for running things locally um so if I want to add a reporter for my local setup then I need to somehow say okay this is my config file and then the cli tool needs to be more smarter on how it modifies this config file to properly you know format the stuff and to probably inject the new service or reporter can you ask a question like to which uh files you want to add this maybe something like that yeah yeah just specify file we are currently modifying I used to have multiple configuration as well especially mobile and web configs usually differs a lot well at least in my experience oh yeah the install command actually has a a flag called config that you can pass the the where your configuration file is and then it will just overwrite that one so that already exists yeah that's for for this let you mean for selenium standalone or no for the web driver cli can you imagine that if uh we ourselves don't even know this command that works this way that are you uh I know it because I I added it right all right cool actually understand okay yeah pretty much the confusion that we had here is pretty much describing the the fact that it's not documented well for our users as well no I guess it would it would be better to build a ui configurator because yeah and no one reads doc documents and it's not not really obvious how to use a cli I mean it's currently built like really good from my point with you but but it still doesn't provide enough level of visualization of what I have now and what can I have and creating the ui configurator it shouldn't be that hard this is you know it's stressed it's a gooey for the cli that we have no so we this is a matter of spinning something up real quick is running the cli in the background Kevin built this already right you have something that was working really well for version four right yeah um you talked about a ui that kind of managed the config file yeah yeah uh it was it was tricky to kind of handle all the different use cases because um yeah part of it was having to read the config file and turn that into a set of form fields that have the defined input and while I could handle like my own case well what if somebody is running their what if they have their their test need to run some commands so sorry in like their package json they have their test script and a lot of times you'll have or I'll add something that like clears out some folders maybe compiles type script down and then runs the wdio command having to allow for that having to allow for very um config files that are a lot more dynamic than um what the basic config file is so um yeah I did have kind of a basic version working um and it was nice I I liked using it because it was a little bit easier to um when I wanted to run certain spec files instead of having to remember what the spec file was I had a file explorer that I could click the spec file I wanted and run just that one that was kind of nice yeah on the subject of um I guess the cli or and or um boilerplate projects and modular reusable frameworks I was one thing that just kind of strikes me it oh is that um as far I haven't actually looked at all the boilerplate projects but I'm not sure that they are really set up using the page object um pattern although I know we have documentation on page objects on the in the documentation but um I went I feel like it would be useful maybe to either have boilerplate projects that um that have a more modular setup or or to have this cli that actually a cli that actually might create template files in a sort of modular in a way and I know that this I mean obviously we want to be flexible we're not trying to you know I think this is also like we were talking about the recorder we I think that's there's almost a different approach right are we are we for developers or are we for like non-developers and so far web driver IO is solidly for developer types which I think is a fine focus but even so yeah I mean I think I see a lot of questions on the Gitter channel about like how to set up was the best way to set up page objects what's the best way to handle it and it seems like that might be useful to have at least more documentation around if not more um we just kind of like add that when you start web driver IO through the config uh we already installed the dependencies but we don't add extra tests to it kind of like this is a test set if you would run this command it would run uh automatically on this website and this is kind of like a page object structure documented with inline documentation if we have it already there then people can already they install the stuff and they have a few files in it that you're a run npm test and the project is running they can see what's happening exactly the babel they got the babel config and then we don't need a complete UI it's nice to have a UI but I think for people to to do the steps with all the installations and then doing the translation for how do I write my test case with web drive radio I think a few sample test cases with a proper page object pattern will be really useful for them exactly I totally agree with with that and we actually have in our company somebody wrote a like a template file generator um so for specific very specific to our framework which is sort of like a five-layer framework is probably not you know not necessarily what we want to standardize but it would um it would actually take a page uh it would be specific to a page you I forget exactly what it did well actually it was it was like it would also um detect your low your all the elements in their locators so it was a little bit in a different direction but that so would detect it would create a locator mapping file and then it would create four other files and that same in that same page as hierarchy like we call them page objects and then we can do this UI services and validation services if you want and like and we use cucumber so like a step step definition files I don't know I mean something yeah it's something like what you're saying but probably simpler just like a google search example I think would be super useful yeah I think I'm going off with what Vim said like um maybe we have we can add like another command to the CLI like init initializes like a default um two or three file tests that test this web driver at your website and then that way they can understand like how to set up a project almost have that already as well by the way cool we do a config minus uh why it will already do like automated setup so we only have to add this to it and we in fact have a project um where this is documented the the project number 10 um which is called uh auto generate sample files which is essentially that way and I had one kind of like proposal a one ticket to define a proposal for this uh where a couple of people including Barry already chunked in me call as well uh so you know for anyone who feels interested in that um that's something we can build out and I could see you know that should be that should be actually straightforward and could provide a lot of value do you think that this would replace the uh the needs for our boiler plates I to be honest I I have to add that I completely agree with that um our well current situation with boiler boiler plates is like it's not that good let's say I mean we have a lot of boiler plates but um quality of the boiler plates are not uh well well they they're good but some of them are not that good if we might want to and also some of them more look like an examples of how to deal with particular issue and uh are not really usable as a boiler plates uh I used to review all of them like uh a year ago or half a year ago or something and I guess only fine for a couple of them that can be more or less usable well in form for my goals but like most of them were either like really really small ones that I can do with like in one minute by myself or huge ones that I need to understand what's going on here and so on but if we can have something like uh something to boost our project with the proper structure we can agree on what structure we can have uh and I guess we would need different structures depending on the framework or even the goal of what should be done I mean mobile web whatever well we can start at least with something uh so yeah it should be should be really helpful that I have just typed npm init uh or whatever uh dash yes and then installed cli and just initialize the project with uh structure with some tests that then I can just run npm run tests and here here we go my tests are already running and I have the entry point where I can start actually proceeding tests or defining my page objects and so on so on so yeah yes should be really helpful yeah yeah I totally agree with that and also to the point of whether we would replace the boiler plates I mean I think the boiler plates would still be really useful as well because especially for people who aren't starting a new framework but you might just want to look at a reference of how to adjust their own tests that could be useful yeah I think also it's a nice incentive for people to contribute something to the project without knowing the technical details of the framework I saw a lot of people making their progress to the boiler code documentation and they were really excited to add their own their own boiler plate and whether or not you know every boiler plate is really custom and every setup is custom and I don't mind just add these to the section but in terms when we add this to the to the cli it needs to be we need to find a fine line between uh useful and small versus too big and too you know too complex all right before we have 10 minutes to go I wanted to just go over the network primitives everything that I have prepared and almost I think I'm almost 50% done with it so I wanted to make network stubbing a little bit easier and wanted to move it away from um the DevTools service and more to the core since Firefox and Chrome and Microsoft Edge will all allow this and I'm in the lucky position to also implement this in SauceLab so it would work locally as well as for people running their tests on Sauce and I have a couple of things that I wanted to show so the general idea is that the browser will get a network property that is the browser.network and then similar to how just works or how knock works where you provide a where you provide a URL for the resource you want to mock and you then get a mock object back and this is I figured this would be would be the nicest thing because this mock object could have a nice could be typed for TypeScript so that you exactly know what you what you can call on it and it's also nice to it makes it easier for me to implement it on the cloud vendor because the I wouldn't need to have to listen to the network events to make dynamic decisions if that makes sense I would like if you the idea here is to if you want to mock and resource using a block stream then you get a mock object back on which you can then call like a response method where you respond a certain payload it can be in this case it's a JSON so if you if you want to mark a REST API you can just say mock respond you could do the things that are really nice and just where you mark certain returns of functions once or multiple times so in here we respond once would return for the first call injected to do and for the second call another injected to do and then after that it would return I don't know what's the you how it would use after how it just works after that you can actually set a response I believe and then a response once twice basically and then yeah it will do the default that's the idea here and so essentially that would be nice and then you can also inject a function that would dynamically return something which also works already in the spool request so here I just go all over all items that I got from the API and change the title and the item from it so that the pretty much it allows it to dynamically change based on the content you get so the response and the response once make a method that allows you to overwrite the response with a JSON object or within with something else as well another thing that was in a board where you can say okay I want to have this respond to fill with something which is pretty straightforward and then which is really nice that you can either clear or restore the difference with clear is that you that the mark still contains like as continues to exist so if the browser calls the same resource it responds with the marked resource but the calls that this resource got which is captured by web.io is then cleared and the reason why I wanted to have that is so you can do things like expect mark to be called three times let's say so you can test for instance how many times the browser is called the specific resource that you have marked out and restore similar to what expect does is just bring back the original resource and remove the mark completely what do you guys think of that I think it looks really good something that I don't see is any any status codes how would that work for example yes so there you can what do you mean with status code in what context because you said you can abort for example but you can also respond yeah so what if I want to have a successful now I want to have a 400 but I also want to have something in the body stating for example an error message oh yeah okay yeah this is indeed missing here let me wear this down that you can modify the header as well as the status code from not only the payload not only the body but also the header and the status code yeah and something else that I think would be very useful to combine so to speak because we're focusing on the mocking part here taking Cyprus as an example here I'm not sure from the top of my head how Descafé is doing this but I know that with Cyprus you can actually do a route and depending on if you modify the object it will either spy or or mock it and if you just spy on it you can actually wait on it for example yeah this is a it's essentially what how this works as well so if you just define the mock like this it will be only a spy so you can still say I want to wait on this specific mock response let me find the one second if I go into wait commands which is already where I only made a prayer for that so actually no this is not the right example I need to update this it's like here if you start mocking a network request then you can wait for a response on that certain mock without having to set like without even need to stop it okay would it also be possible to just wait for a response without passing an object uh yeah okay I think this is just you know I wait for a response and I like like with wait until and all the other wait function it has a timeout in an interval but you can also just say uh mock dot wait for response without anything and would take the default values no like in in line 17 though yeah exactly yeah all right yeah awesome yeah so yeah this is exactly what you mean I think this this is going to be great yeah like for for websites that use apis not all websites use apis and that's its own struggle but I would love to see something like this I mean you should I it should be possible to also respond within a 64 image if you want to mock images or javascript files the idea was that you can where is it that you can be like I don't know provide maybe a url resource and say you know just redirect to that resource see I don't have that in here that was one of the others things I want to have so that you say respond and then you provide some like a url to a file and if that exists uh let's say file.js and if that file existed we'll respond with that certain file or it will redirect if it's like an hdps uh it can redirect to that resource so that should be should allow you to mock everything you know based on our other resources so in separates uh go back to Armin Wang so they have this concept of stopping and spy stop spy and fixture I think so spy meaning you just observe the network traffic but you're not you you're not doing anything you're just watching uh I don't see we have a method here like doing doing that and so they're uh stopping I think it's the in our case it's mocking uh so stopping meaning like your intercept the network traffic the API call and replace the the real response with the um with your own uh mocking uh return response but in separates I have used the fixture so you're just you know reading the JSON file you know fixture folder and respond with that um well that's your gospel too right if you define the mock I mean this is just the internal way how you define it but if you define the mock you automatically spy on it and you can say you can just listen how many calls has been made to it um like how many how often the browser has called this resource and once you call like once you call us uh like uh once you call us respond or abort or something like that then you actually stop it like here yeah but uh so they have the option of just like watching like spying not doing anything or and also if you want to do any something that you do you you you calling the stopping to replace with the fixture so uh another point is like uh so this only supports REST API I'm assuming uh does it support the like web socket web socket call oh web socket is interesting um no not this yet uh but let's me make a note for that so I can create the tickets yeah I think the Cypress is um I haven't seen they have some example for a web socket but uh I haven't like um dig into their strong field so to speak yeah I'm not sure uh mocking socket connections is actually possible in Chrome to be honest that I think it's like you're uh establishing some um um server um uh like using the because the web socket call is just like an upgrade right upgrade of the HTTP HTTP 1 to HTTP 1.2 something like it's like an upgrade then you you basically establish a like a fake server then uh whatever the call to the web socket call we route it to that server I think then they respond with whatever the the one you want to feature or fake yeah I mean if that's possible um we should definitely consider implementing that but so far um I I doubt that this is really possible in I think that yeah this is a good for the first step you know I'm talking about probably in the future maybe we want and support for the web socket call because um yeah there's a lot of a use case for for that um so a couple of other things that uh also currently working on is just setting the user agent which is um helpful in some use cases actually no actually it feels this one because this is a changing or serving websites with different that based on your user agent is uh uh not considered to be a good way of doing things these days so I remove that if it comes up again that we want that someone needs it we can reiterate it should be something fairly straightforward to implement um I wanted to implement some network oh I was I skipped this as well uh because it was kind of difficult to implement okay sorry about that so this will also not help me at least not I will not use focus on that but the one that is always there is the throttling uh so you can throttle on a specific type uh that is predefined or on your custom on your custom way which is pretty straightforward so yeah those are uh request I'm I had struggled with the first pull request um to get it working at CICD but this has passed just a couple of hours ago uh so I will make sure to update my other pull request and then I want to merge everything in this one thing and merge and ship this feature as a whole um in one of the next versions um and then we will see how how people will use that and if they like it come up Christian currently it's already possible with web drive it to do the throttling run uh no it's not just uh for I'm not sure if chrome allows it chrome has like a custom endpoint but it's not part of the web pair protocol uh right yeah that could be it like sauce that I built a sauce and it worked on extension and sauce let's do allow customers who run the testing sauce doing that stuff uh but it's not the chrome browser feature yet cool looking forward to it awesome um yeah I think we are on top of the hour um I don't want to steal your guys too much time um anyone else has something to bring up what talk about can we do this sometime again like in the future make it regular like office hour I know separates and now separates actually we're doing the office hour right I would suggest the set is doing the same thing but yeah it's a super helpful and uh we can maybe set up like a regular maybe a quarter quarterly meetup or something yeah I would be totally down for that um I could I can see how like I can I can make myself a note and um we can then schedule something for the end of next quarter and then you know check in um if you guys are down to that I'm absolutely I will definitely down for that yeah that would be great and yeah if you haven't seen that yet um I am offering now uh work without open office hours uh so I've blocked four hours a week on Wednesday if people want to work on certain issues and poor requests if they need help implementing teachers and uh I had really really successful sessions yesterday one with Olga and the other one with uh Alexander who's working for the browser company uh she wanted she was working on upgrading Spectrum to version six of work level and we got it running within that session which is really awesome um so I've met one session next week and if you guys want to you know do the same um I can add you to this calendary thing which I'm using and um you know you can you can help some other people as well but uh yeah I think I'm going to do this for the next couple of months now and see how successful that is it's a fixed time I believe now right yeah you can define which hours you want to be available for someone and then the person who books the appointment pretty much chooses um between your options all right now you can add me to that list yeah yeah uh then you just send me the hours that you want to be available um and I can add it to the calendar what is the every Thursday what time currently I have it um on Wednesday uh 10 to 12 am uh dupian time and um I think what was the other one uh 9 to 11 am uh San Francisco Pacific time so so if you want to work on a ticket uh then let me know and we can work together on this you can add me to that office hour like for the San Francisco time I'll try awesome um all right uh thank you everyone for joining um let's do this every quarter and yeah if you have you know let's continue talking on the giddler chat and um continue working work tomorrow thank you everyone have a good day thank you have a good day thank you bye bye