Picks

Hello, and welcome to another episode of adventuresin.net. I'm Sean Klevy, your host. And with me today are only Mark Miller, the one and only. Hey, kids. Hey, Mark.

How are you doing? I'm doing pretty good. Yeah? Yeah? Yeah?

What's it like in Spain today? You know, it was a little cold, but, you know, sunny. I live in Valencia, so it's, you know, the weather's pretty good. It's got 300 plus days of sunshine every year, so it's generally pretty good. Must be nice.

Must be nice. It's not bad. I'm, you know, indoors writing code all day, though. That's what I'm doing. Let's, welcome our guests, for today.

Let's welcome Dario, and I'll let you say your last name, because I probably will mess that one up. Yeah. You know that I think I I never say my last name in English. So my last name is Kondratyuk. So, I never heard anyone say my yeah.

Kondratyuk. Yeah. Yeah. Exactly. Yeah.

It's Ukrainian. Very nice. Nice to have you on the show, Dede. Can I can I just call you mister Konrad Gook? Can I do that?

Did I get it right? I think if you try that for the next, for the next hour, maybe the last one would be great. So I'm gonna get it right. I'll do it. So, no, let's do something.

I would the challenge is to say my name, Dario, properly. You're in Spain, so I bet you would say Dario properly. Dario? Dario? You're close to Dario?

It's like Dario. It's like Dario. Dario. Dario. Dario.

Dario. Dario. Dario. Dario. Dario.

Dario. Oh, yeah. That's what I'm saying. Alright. So, while you get us started off by telling us a little bit about yourself, you know, how you got into development, how you get into dot net, and what kind of things you work on today.

Yeah. So well, I'm Dario. I'm I'm from Argentina. It's cold, down here today. So, I'm quite old, but not that old.

You know? I'm 40 something, early 40. So That's a relevant thing. Yeah. Yeah.

Yeah. It's a relevant thing. Absolutely. But just for to one thing to say is that I've been coding in dot net since the first beta 2 version that came in 1 DVD, those MSDN, you know, boxes, and you know? Yeah.

So, beta2.netframework. Yeah. The beta2 version 1. So, yeah, been coding. And before that, I I'm not those people that coding, like, since they were a kid.

You know? I started, like, late in the teens. You know? So my first language was bb6. So one of my first tasks was trying to sell c sharp to the bb6 people, you know, old people back then, you know, in the first gig I was working at.

So, yeah, c sharp developers since then. Then, yeah, was was doing consulting for many years. And 6 years ago, 7 7 years ago, I got into the browser automation world. There was Puppeteer. I bet maybe you heard about Puppeteer.

We would talk a lot about that, back then. So I think 6 years ago, Google created Puppeteer, the beta version. So I I got into Puppeteer then. I said, hey. You know, I should get that into dot net.

So I start creating a port. You know, I I don't know. These days, it's not that popular. But back then, you know, in in those 6, 7 years ago, having the ports, you know, from Java, r w, you have the j the the dotnet something, you know, the dotnet this at work pretty much ports from Java to the dotnet. So I say, hey.

Why don't we have this, puppeteer that was in in node the node library? Why don't we have that in in dotnet? So I created a port from puppeteer, called puppeteer sharp. Puppeteer v one was released, a few months after that and got pretty popular, as my version was the, you know, the the dot net version of Papadia on the very first v one version. So I can say that that became a really very popular dot net library for browser automation.

So, yeah, many years on Papadia. Then a playwright came. Then we would talk maybe about the story. I will I say when playwright, came, I said, hey. We did what?

Playwright Sharp. You know? So I did a playwright Sharp version. I I work super close to, with the playwright team. Then the playwright team say, hey.

You know, we won, like, an entire ecosystem of all the languages in Playwright. So I donated, my source code to, Microsoft, and then that became, playwright.net. And that took me to the company I work in now. It's called Mable, where we do, low code, quality browser automation. So now I'm putting all my expertise in in browser automation and in playwriting in Mable.

So, yeah, that's my journey in, I don't know, 3 minutes, 4 minutes. So why why don't you give us a little bit of an overview of what book Puppeteer is, what it does, you know, why would why you would use it? Yeah. Absolutely. So I think the the old guy in in the browser automation world, it's Selenium.

Maybe I don't know how many people work with with Selenium that, our listeners, but, Selenium was like the big, library that it's still one of the most popular library for doing what it's called end to end testing. So what's end to end testing in a few minutes? And to end testing is you have unit test where, you know, you test. Okay. If I have this add two number function and I pass 2 and I pass 2 and evaluate that is 4, that's and you're testing.

I hope everybody that is listens to this podcast, do unit testing. Then you have integration testing that it's that, okay, I will go call this API or I will call this service, and I will inject these dependencies and things become, you know, more you test more integration between different components. And then the peak of the testing pyramid, it's end to end where basically you go we we are talking about browser or or websites. You basically go to the website and programmatically simulate the user interaction, and you validate how the website website reacts to that. So this is pretty pretty much an end to end testing, 101.

So Papetir what Papetir did, they said, okay. Selenium is one thing. It's I don't say that I I will hate I I hate Selenium, but I hate Selenium. So and maybe many many developers also hate Selenium. So 6 years ago, Papeteer, one of the crazy, super smart programmers, developers in Google, they say, hey.

We have the the dev tools in Chrome. And so, you know, the dev tools what is the that tool is the thing that the box you have below the browser where you can go and see the elements and you can debug your JavaScript. So that's, like, dev tools. So Chromium, they have one thing that it's it's called the Chromium developer protocol. So it's basically what it's between the browser engine and that black box.

So they have a protocol that the black box talks to the browser. So every time you click on an element in the dev, in the developer tools, it sends a message to the real browser that it's doing the real stuff. So one some Google people say, hey. Why don't we make a library so you can interact with the browser in the same way that the dev tools interact with the browser? So Puppeteer did basically, it's a library that allows you to do pretty much everything that you do with the browser in the dev tools, but programmatica but in the programmatic way.

So you create a browser. You launch a browser. You say, I want to create a new page. I want to navigate to that page. I want to fill that data.

I want to click on that input, and then I want to even execute, JavaScript. And that's Puppeteer. So Puppeteer is pretty much a a generic browser automation library, so you can do whatever you want. So there are many things that you can do with browser automation. End to end testing, I I mentioned that with Selenium, it's 1.

So you test website. But there are some other people using Puppeteer for other things. Scraping. What is scraping? Scraping is going to a website and trying to automate actions to extract information from that website.

So for instance, you can write a piece of code to book try to book a flight from Buenos Aires to Valencia and do that every day and get the report when the price is low and then try to purchase that ticket there. So it's browser automation in a generic way. Scraping is 1, so, doing testing is another thing. So there are really another awesome ways to to do browser automation is to generate PDF files, and that's a pretty nice thing. So as your automation are automating Chromium so you can go to a website and do print to PDF, and you get the PDF file.

Then another thing that you can do that is pretty neat, it's you can take a screenshot. So let's say, for instance, you can inject HTML, take a screenshot, and then you have a thumbnail generator that if you put that in one Azure function, then you magically have something to create some thumbnail or some something pulled from dynamically using the browser. So even even more. So you can inject code, take a screenshot, create a PDF. So there are many, many, many things that you can do with, browser automation.

Can can you get us, can you tell, like, what browser has, what kind of what browser has focus inside Windows? So if I were to put to use this inside of a a a Windows application, for example, or or something running on a Windows machine, can I can I work with and talk and basically say, are you you know, what's the browser that's out there? And then ask, like, what element on the page has focus? Can I do things like that? So if you so so first, you have to be the one launching the browser.

So you can't pick any browser around there. And even now, if you automate Chromium and you launch a browser, you will see a bar saying, hey. This has been automated. So this browser is yeah. So it's a it's a is it a command line parameter to launching the browser?

How do we how do we signal that it we're gonna have a session where we're automating? So, it's a it's a command line argument that you can do with Chrome. So, that that's a good question because you can grab your own browser, with a command line argument, open that, and it's using WebSockets between the the your library and and the browser itself. But programmatically speaking, in Puppeteer, you go and say, okay, Puppeteer, launch a new browser and you get the browser object. And then you say, okay, browser object, new page, and it gives you a new page.

And from there from there, you can say, okay. Which is the tab that is active, active? What is the element inside that page that is, is focused? Or even you can bring, a tab to front. So maybe you can have many windows, and you can bring a tab to front.

But you, you interact with the browser that you launched. I see. And these browsers, they can they can be both you know, when I've used tools like this, they can have a a head or a headless version. Right? So if you wanna watch and see what it's actually doing as it's going along, you can actually watch it open the browser and do all these things.

But most often, when you're using it for actual testing in a in a CICD pipeline or something like that, you're gonna run it in a headless version, which actually doesn't even have a display as just running in the background somewhere. Right? Yeah. Exactly. So that's the so, yeah, you can this is you hear a lot about, like, headless browser automation because in most of them, you want to run the browser, like and you don't want to see the browser because it's, something that you don't need to to see a browser.

So there is something pretty neat, and it's interesting because back then, 6 and even maybe 1 year ago or 2 years ago, Chromium has had two lines of code. Maybe they have one renderer for headful that you see the browser, and then they have another renderer for headless. So that caused that in some cases, the browser didn't behave the same when you run head 4. You see the browser and when you run headless. So maybe you print to PDF in headless and you didn't see the same result as in head 4.

So I think a few months ago, I I think it's not even a year ago, Google launched something called Chrome from testing. So they launched a Chrome browser, which is specifically launched or created for testing, they unify that goal. So they unify the headless and the headful, and now it's under 1, single code base. And one thing interesting that it didn't it was hard to to do before, Chrome for testing, and and I bet maybe you you suffer that is that when you download Chrome, you download the latest version. There is no way to say, hey.

I really like, Chrome 110, you know, and and I want to download 110 because my code was working perfectly fine with, Chromium 110. You you couldn't do that. Now with Chrome from testing, they have some storage where you can download any version that you want. So Chrome front testing was some small thing maybe for the open public, but if you do browser automation or do, end to end testing with Chrome, was it this thing of unifying headless and headful and being able to pick a Chromium a Chrome version. It's, it was pretty good.

And, you know, I I mentioned a lot Chrome and Chromium because Chromium, it's an engine. It's it's the it's the Chrome without all the Google brand. So it's a version that you can download. It doesn't have any Google login, all all the things that gmail, all all the good things that it's without all that. But maybe you want to try the real Chrome that people download, and and that was pretty problematic having 1 Chrome inversion and not being able to use a specific version of Chrome, to test your code or to run your end to end testing.

So that's a few things that, Google was working on and and was changing over time. And speaking of I'm I'm talking about Chromium. How about other browsers? We have, unfortunately, the other browser are not that popular, but, we still need, to have more browsers, in in the web. If you are a web lover, as I am, we know that we need more browsers.

We need more people use it calling different browser. So when we talk about Chromium browsers, they are all pretty much the same. So testing in Chrome, testing in Edge, Play Red and Puppeteer, they support Edge, but it's pretty much the same. With with Firefox, it's different. So what the the Mozilla team tried to do something on on to support CDP calls, this Chrome developer protocol, but with it's, like, half cooked.

It's not really there. And the playwright team, they build their own FireFox field with all the support they need to automate browser automation using Playwright. The other browser that we would love to have more control over, and we can't, it's Safari. Safari, it's it's the it's the one that, it's. So what the playwright team did is they're they they created or they're building a WebKit browser.

So in the same way that Chromium, it's, for to Chrome, WebKit is the engine that Safari use it uses. So you have the WebKit that is the what you see, what's what builds the the render, and what on Safari, it's all around. So to try to overcome this Safari limitation of, mobile automate Safari, Playwright, they they have and they created 1 WebKit build that is not perfect, but at least help you do some brow browser automation on what it could be something super similar to Safari in iOS or Safari on on macOS. Tario, I'm interested in the differences between Playwright and Puppeteer. They both seem like they address similar problems.

Can you tell me a little bit about that? Yes. Yes. And and it's great to to know the difference and and know, why we let's say why we why we need both. I think, one thing I love about open source is not about the winner, but it's about having opportunities, having, you know, the the the chance to to pick, whatever you like.

So Palpatine was created, for, by by a play by a Google team to automate Chrome. And and that's the that's the goal. So the the the but this goal is so you can are able to automate Chrome as much as possible, trying to do even, I don't know, mobile emulation. And they have some, for different kind of color problem that people can could have in their eyes. So you can you can test all that.

So there are many there are many, many, many things that you can do. So will try to expose everything they can from the browser to your dot net in in the case of my library or or the or in JavaScript. I so you know how Google is? You know, maybe, they didn't they pause the project. You know?

They they they say, hey. Maybe you would not need Puppeteer. Maybe we have to invest on some this in in developers in in another tools. And some developers say, no. So they they cross, you know, the the street, and they went to Microsoft.

And they say, hey. You know, we have this great idea. And so many of the of the people from created, Playwright under the Microsoft umbrella. And what is interesting about Playwright is that Playwright was created as an end to end automation tool. So and and that's their focus, and that's the the API, and that's what they think about.

You know? It's end to end testing. For browsers. Only browsers. Right?

All yes. For browsers, only browsers. Yeah. Okay. So and you can see, for instance, that they they created their own test runner in in in typescript.

So and and and they have all the assertions, all the things thought for end to end testing. So and and it's interesting how the philosophy you can have for a library shapes the the the the end product. So you have so so both libraries automate the browser. Both library have have a have a click. You know, you have you can type.

You can create a page. But one is puppeteers thought, hey. If you want to do web scraping, do web scraping. And player will say, yeah. You can do web scraping, but, we are we are we think about engine testing.

Our users are QA people. You know, our persona is people that want who wants to test, their application. So and and from that, if you create a ticket, you playwright, say, hey. I want to scrape this website. They might say, yeah.

You know, we don't care about you know, it's like it's not our use case. You know, the typical, what's the use case? You know? What's your use case? So, basically, that's the main difference.

You know? Fabrizio is a general, web browser automation library, and Playwright is an end to end browser automation tool. So what's it take to to write these automation scripts? Is it easy? Is it difficult?

You know? And, you know, what languages can you choose from? Yeah. So in puppeteer, the the puppeteer library, it's written in in TypeScript, but it's if you go to one example, it's with 5 lines so you can print PDF. It's, puppeteer launch, the browser new page, browser page go to, page screenshot, page PDF.

It's as simple as that. And it's and that's what's great compared with Selenium. Because in Selenium, you have to download the driver. You have to see what the driver is. You have to connect that.

It's, it's complicated. So both in in Palatir, playwright, it's in 5 line. You can get started. You can go to the website. PPTR.

Dev, it's, the puppeteer website. Playwright. Dev, it's a playwright's website. So I'm the owner create no. I'm not the owner because it's my open source project.

It's for the community, by the community, so I don't I don't own, the project. It's a we you own the project, Sean. You own the project, Mark. Papadero Sharp. It's a dot net library, by the community, for the community, that it's a port in dot net that tries to replicate pretty much everything that you can do in Taskade.

You can do it in dot net. And that's my goal. My goal is giving that library, to, to play right to, the net developers who wants to do browser automation. And that's my my boy, you know, my kid, 6 years old. He's now and and that's, what I might maintain.

In play rates well, play rates pretty much the same, and and I will mention some differences. So playwrites TypeScript first, the same as puppeteer. But what playwright did clever they are super clever, super smart people. So they package their the playwright library, and they're using they're using that as a driver for other languages. So then you have the playwright on that library.

You have the playwright in Python, and you have playwright in Java. But they're quite thin libraries. So those playwright.net, they talk to the dotnet driver, you know, and put that message in. So the click is okay. No.

Do a click, and and the driver will reply with with the answer and and so forth. So native, both its typescript. In Puppeteer Sharp, my library, it's also native because I I'm I'm connecting straight to the browser. There is no driver in between. It's a, yeah, it's a big library like over here.

Although Playwright is TypeScript first, and they they use TypeScript. They use the driver, and they have, like, bindings in net dot net in Java and in Python, that talks to this, the dot net or node library that is running in the background. So that also it's makes a difference in dotnet because, I think the play property is pretty much lightweight because it's, just talks to the browser. Whereas playwrightin.net, you need you need to execute node. So your Docker container, if you run that in the Docker, also needs node.

Your machine, if you're running that, also, needs to run a node in in in the in the back end. So that's maybe the the main difference. But in flavor well, in flavor playwright has, these 4 flavor. And in Python, you have the sync version if you want to program program and code that synchronously or the async version to prompt, async. It turns out that Python, you know, there are some sync people and there is some async people, so they have the the two flavors there.

So say I've got a big complicated multistep form process that I wanna, you know, automate for testing purposes and things like that that might have, like, some external authentication that it needs to get into. Is that something that Puppeteer and and Playwright can do? Do I need to write that code line by line to automate all that? So, one one one thing that it's pretty neat in so if you don't do it and for me, if you do end to end testing, go to Playwright because, their their goal is end to end testing. So, even if it's non binary.

Now if you do end to end testing, go to Playwright because they're thinking about that. They have really good resources. So Playwright has a code generate code generator. So you have a recorder. So you can open a recorder in Playwright, and it you say, okay.

I want to generate bounded code based on on on that. So they will open a browser. They will open a recorder, and then you would act on the page, and it will record. It will try to record it. It's best.

You know, maybe you you then have to go and and tweak that, but they will they will create a really good, test, from from what you are doing in your in the website. So it's a good way to to start, working with with the playwright with the playwright, and you learn how things work. You know? So the recordings, it's pretty cool. Can I handle oh, go ahead, Mark?

Sorry. Can I create essentially, like, something that waits for a value or an event to occur, like a click or a field to be filled out or a password to be entered or something like that? Can I, in other words, create, like, a a maybe a script that would be interactive in some way? Okay. I got you.

So let me go back a little. One one cool difference different, with Playwright compared to Puppeteer. So, again, Puppeteer is browser automation. You type, send the type, and that's it. You click, you should you click, and that's it.

Playwright as is thought for testing, they have auto waiting, and it's pretty cool. So if you say, well, I want to click on the same button. What if the button's not there yet? So playwright will fail. You know, it's like, you tell me to click.

I tried to click. The element is not there. I'm so sorry. Playwright will retry, for 30 seconds till the element is till the element is it's there. It's visible, and it's actionable.

It's, it's enabled and it's editable in case of typing. So that was maybe the first thing. I think you're you're thinking maybe something about interaction with a user that sees the browser. Right? Yeah.

Like somebody who's gonna maybe be, either the the user's going to do it or maybe there's something else that's that I'm making a call to that's gonna take some time to get some data, but I want the script to continue once the data has been entered or something along those lines. Maybe I'm just imagining some other process in another thread, and I'm waiting for that to finish, or maybe a human entering, like I say, a password or some authentication kind of thing to get past that. I'm just Yeah. That's Lot of lot Lot of lot of, both Playwright and Puppeteer, they have, well, 1st Playwright has has auto waiting, so you can wait till a grid is there. You can wait till no.

Save button is there. But both has a wait for many wait for functions. So and, you know, if you are in .net, you you know that you can create a task, grab that task into a variable, and then you do the wait of that task further on. You know? So you you have this, task, you know, play that that you do a lot when you do browser animation.

Okay. I want to click and wait for this. I want to type and wait for that. So you have wait for element. So I want to wait till that element is there.

The task will resolve when the element is there. You can wait for a function. So you can write a JavaScript function that will be executed in the browser, and that task will be resolved when that function returns truthfully, value. So there are many so wait for an element, it's 1, and wait for a function, in in the browser, it's another one. If I'm writing that JavaScript function, is that just a string in my c sharp code, or would there be some other better way to do that?

Yeah. Well, in TypeScript, as the code is JavaScript and the browser talks JavaScript, you write JavaScript just plain in the code and that code runs in the browser. Whereas in c sharp, it's quite, you know, you can't make 2 languages. So in c sharp, that's a that's an string. So your code is a string.

It's ugly, but many, many times you see Puppeteer users in TypeScript that gets confused about what code it's running in your process and what code it's running in the browser because it's all JavaScript. So you have to be very clear that this of variables. Hey. Yo. This I disevaluate this using this variable.

Yeah. But this variable is no. And you're running that code in JavaScript. So the compiler says that it's it's good for the compiler, but then when you run the code in the browser, the variable is not there. So doing everything in JavaScript, it could be, you know, you need to be smart or thoughtful about the variables and the scope and all that.

Whereas in in c Java, as in as in it's in a string, it's super easy to to to do a binary. No? And I just wanna confirm, we were talking about, calls to waiting for the button and the sophistication that's in Playwright. I think I heard you say Playwright will fail, but I think you meant puppeteer will fail in that, and Playwright will succeed because it's it's got kind of a richer API and that it's waiting for the button to create. Is that correct?

Yeah. Exactly. So Okay. Most of the actions in Playwright, I would say I I think I could say all that, but, you know, I'm missing. But I I would let's say most of the action in Playwright, they have auto wait and they have a time out setting.

So by default, every action waits or retries for 30 seconds. So if you say I want to click and and I want to click on this element, they will they call it actionable actionability check. So they will see that the element is there. If if I type in, is the input enable? It's the the the input, you know, or or it's in the viewport.

You know? It's it's something that's on top. I can click here or I have a a a a pop up, you know, or a dialogue on top of that. You know? So probably they will fail.

It may they all have retried, but Playwright has all and I think they added value of of retried. Enable that it's the company I work for that is a low code. They have things on top of Playwright. For instance, they will try to dismiss pop ups, you know, or try to to click in different places if if the click fails. So it's like and it's a low code way.

So maybe it's fully low code, so you don't have to learn. So so you have to go. So yeah. So we have the 3 levels, you know, of, which So so what does development typically look like? Is it as simple as, you know, writing a couple lines of code and running and it's always gonna be there?

Or in the process of development, are you stepping through the code and kind of watching the browser and seeing what's being filled out, or do you use the recording tool like you're talking about, record, and then create your test case from that, and you just don't ever look at it again? What what is typically what what kinds of things do you do you experience during this process that that make, you know, the process, I guess, require a human being, I guess? Yeah. So, first, I I would try to always have in your in the top of your mind the pyramid. You know?

You need a lot of unit tests, tons of unit tests, many, iteration tests. And in the top, you need some end to end test. So, yeah, as a as a developer, let's say let's say you are, I don't know, a React developer or any component, you know, the razor or or laser or whatever. So the first thing you need to do is write the unit test for the functionality you have there. Okay.

And then, okay, I have this component. If I render this component, they say, hello. Perfect. That's my unit test. It's fast.

It's not flaky. I didn't use the for the word flaky. I will mention that. It's it's something that happens a lot. Then you have the integration test.

Okay. How this big component, this container works with everything. It's that's in your in your daily world. You're you're you're paid for 2 great web pages, let's say, if you are a web developer. So the the unit test is part of your quality process.

So first unit test, then integration test, and then say, okay. I have this typical to do list. Okay. Let's go to the page. Let's log in.

Let's add something here. Let's save. And I when in in when you get to the end to end, part of the testing, you think about flows. You test flows. So I test the login.

I test going to the dashboard, and my data is there. I test. I create, this invoice, and the value is right. So when when you you get to the to the end to end point, you start thinking about flows, and that's what you think. Because I I I don't get about any or or all the combinations because I have unit tests for that, but I want to see that the flow is working.

I want to see that, that the page is working as expected. You know? There there are many terms regression test. You know? I want to before going to production, to see, okay.

Every page, it's working as it's supposed to to work. You know? Those I I think when you go up in the testing pyramid, you are changing your your mindset. You know? Unit testing is like, okay.

Every branch in my code is important. Branch in my code is testing. You know? The the the integration. Okay.

This piece is supposed to work with this container, and then I go to end. Okay. To end to end. Okay. This is the flow.

This is how the user would go to my website, and this is what they will do. This is what, I I am supposed to test. So I've got the flow, and I wanna create that. Typically, how do I do that with Playwright? Am I going to record the sequence like you're describing and then maybe add some code to check the the values are correct?

Yep. Or or what does that look like? Do I ever am I ever stepping through the code? Does that happen typically? Or is it never or do I just watch the whole thing and Yeah.

Keep What is it what is that like? So what it's like to be a developer? Let's say that you don't have a project, no test project. So you go new project. I want to create a new, my website dot test project.

I say, okay. I want to test, the the login flow. I go there, new test, login test dot c s. I'm Playwright recommends, end unit because end unit has good, multithreading, and it's better, for, for multithreading test, than x unit. So you have your end unit library.

You add the playwright library, and you create and let's say you use the recorder. So you can do playwright, code gen, and you can record a test. They will give you one snippet, that piece of scope, that you would copy to your test that it's as it's it's it could look pretty much the same as any unit testing in how it looks. But instead of creating an object, it will create a page. From there and and that's a good question.

Unit tests, are super easy compared to end to end testing because if I have the function add two numbers, 2+2 will never be flaky. Flaky, means that the test some sometimes fails and sometimes passes, and it depends on the environment. You know? Some it's like the web. You know?

So the page sometimes takes longer, and sometimes, you know, it's fast. And you don't have that in in unit test. 2+2, it's 4. So you will debug your test and you will see the browser. You will run the testing head full.

You will see the browser and you might end up going step by step saying, you know, why this click didn't work. And it turns out that you forgot to add this checkbox or you forgot to, type this. And if you're using complex component, like, you know, this weird drop down list that are, you know, lazy and they go to the website. You might have to tweak and Android testing are more flaky or are flaky by nature because the Internet is flaky. I always say that.

You know? The Internet is flaky. Internet sometimes works. Sometimes, you know, network, it's flaky. So when there is network involved.

So and that's why tools like Playwright has to retry and you have time to wait. It's important, but, yeah, it's pretty much you can debug and and and it's something that, that's why you you don't have you have as a developer, you need some end to end testing, but not as many as as any unit. If you're kind of QA team as as Dave as Mabel has, maybe you can have some developer that his role is to write end to end test, you know, to create end to end test. But that's the role. And, yeah, create as many tests as you want.

But as a developer, the test improvement is important. So so if I create the test, do I have the ability to run that one test under multiple browsers? Do I have a or is the test dedicated to a single browser? No. You can run the test the same test against, Chromium, Firefox, well, Edge, and WebKit.

Yep. In Firefox that change, is it a line of code, or is it a data parameter to the test? How do I how do I do that? In in dot net, it will be ascending the config. Okay.

In TypeScript, you can have many project in the in the Playwright test runner, but it's for TypeScript, sadly. You can have many project and they would command lang argument, say, okay. I want to run test with Playwright deals with with Chromium or with Firefox. In the net, it's a config. It's not a big deal, but, yeah, with the just one config change, we even change the browser.

Okay. So a lot of applications use things like external authentication, like Microsoft or Google or Facebook to log in, and sometimes this is log in in a different tab. Can Puppeteer and Playwright handle things like that? Yes. First answer is yes.

With the Microsoft audit authentication, it's I don't know if it's easy, but it's possible. Google authentication could be a headache because they don't want robots. Because at the end of the day, what we are calling, it's a it's a robot, let's say. So Google authentication, it's tough because it will reject, your code, your browser automation many, many times. And, yeah, that's a headache.

Some people overcome that, but, you know, but Google is trying to get ahead of that. Because imagine if you are if you are Google, you have a lot of developers trying to do nasty thing against your website. You know? They maybe prioritize, not getting about trying to log in to your Gmail account rather than you using your, your go for web automation. So, Google, I know that it's it's quite a a headache.

I think Facebook it's Facebook Facebook it's, it's working, I think. Outlook, for sure, it's working. I saw many many tested on test on on Outlook. But, yeah, Google can be a headache. And say I I have a suite of tests automation tests that I've got developed, and each one of them requires a login.

Does does it every one of those tests have to go through those login thing over to do the tests, you know, and slow it down? So without getting because, yeah, that could be a whole conversation. But it's a there is a pattern in in end to end testing that call page object model. So, basically, you reuse code. So you have the page, the page of your model, the POM.

You know? You have the login POM with a function login. So, yeah, all the all the tests will call that login method that have has those 5 lines to log in. But is there a way to log in once and then have all the other tests reuse that login? You can you can persist your session state, from the browser in the file system.

So you can make, like, a before all. You can you can make the first test, to log in and save. It's like saving, like, when you close the browser that your cookies are not saved. So, basically, you save all your all the state of your browser, and then every every test that launch a new browser will start from that state. So that's one way to log in only once, for your entire test suite.

And how do these tools handle issues like cores? Like your browser. So it's Okay. Makes sense. Yeah.

So and that's and that's a good thing. You know, you're you're testing your browser. So So, anything else that we haven't covered that, people should know about either puppeteer or playwright or or I guess in the the dot net version, you're writing c sharp instead of types TypeScript? Yeah. Exactly.

Yeah. Maybe to encourage I I think if maybe if we cover something or not, you know, one thing or the other, I I think we will miss much. But maybe my takeaway for the dot net people, it's to now we have the tools. They that's that's maybe the takeaway of the of this talk. You know?

We we saw puppeteer, for a long time. We saw many people, you know, in the react war, in the node war that maybe they have more access to do end to end testing. And and now, we we have the same access to to do pre and also for for for all the platform. You know? We we know with Playwright, we have a great tool to go into and testing that some but before with Selenium was a was a pain, you know, to to do that because it was so painful to to write this and no one wants to be.

It was even if I swear like that. You know? If it's painful and and it's for not part of the problem, you know, we we don't maybe write 1, but then we will forget. But I think, take advantage that we have the tools now. Playwright has a great tooling, whether you are in in TypeScript, whether you are in dot net.

Honestly, the Playwright for the for TypeScript, it's a few steps, ahead in terms of tooling. But then you have we have, playwright has some traces that then you can see the result of the test step by step screenshots, how the page looks looked when on every step. So if you run your test on CICD and some test fails, you can download that trace and see what happened on every step. So we got again, the takeaway, we have great tools. Play rates are an awesome tool, and it's time to don't let developers to to get, you know, more more involved into into quality, you know.

Okay. With that, I think we'll, move on to picks. Mark, do you wanna go first with your pick today? I will. It is, 3 Body Problem on Netflix.

It's kind of a sci fi futuristic series. I'm loving it so far. I've been I think I've watched about 3 or 4 episodes. Very, very interesting, kind of intriguing. Maybe there should I should point out it's there's some kind of over the top violence in some some places, so maybe not for little kids, but, aside from that, real interesting sci fi story.

I'm liking it so far. So what is the 3 body problem? Well, essentially, so far, the 3 bodies are, essentially celestial bodies. That's your, spoiler alert for at least what I've got so far. And, yeah, it's basically about tracking the motion.

If you've got, for example, 3 gravitational bodies that are like suns, for example, and you've got a a planet that's in kind of somewhat of an orbit around all 3, the question is how do you predict the movement? That's essentially what what we're, what we're what where the title is apparently coming from at this point in my knowledge. Don't ask me other questions. I will give you spoilers. And they somehow make that violent.

Planets and suns are moving. Well, yeah. The cool thing about it is that scientists are in jeopardy, and it's a really interesting take on kind of sometimes, you know, things that happen when you have a, like a a dictatorship or, you know, often dictatorships wanna suppress the truth and or crazy radical ideas. So, you know, the intellectuals and the scientists and the artists are typically the first ones that are, you know, shut down in terms of voices. And so that from that kind of a thematic standpoint, it explores that I think to some degree, and I I I find that kind of interesting.

K. Alright, Bart. Dario, what's your pick? So I have a great dish for you to to have a to have dinner while you watch that movie. My wife yesterday asked me to cook carbonara and say, no.

I'm not a cook. You know? What's what's the carbonara? And I found that it's super easy, 5 elements to, to have a great dinner. You need spaghetti, and then you grab a pan with bacon, garlic.

And you then put the spaghetti on that bacon and garlic. And on top, you put Parmesan cheese and eggs, yolk. And you mix all that while the pan is hot, and 5 elements a developer can make carbonara. You know? So When Only only egg yolk.

Right? Only the egg yolk? Only Okay. Yeah. Exactly.

Alright. I'm on it. And what is there oil in the pan, or is it just getting the oil from the bacon? It dep yeah. It depends on the bacon.

I I think it it depends there. I think if you're in Spain, I think you will have great bacon there. Yeah. So I'm on a ketogenic diet, so I can't have pasta. But I've got, like, a fake pasta that I can get that's made out of egg whites, essentially, and it holds its own texture.

So I'm actually, that's really intriguing for me. I'm gonna I'm gonna when I get those egg white, pasta spaghetti pasta sim you know, whatever this the substitute is, when I get my hands on that, I'm actually gonna first thing I think I'm gonna do is gonna do the I'm gonna build this. Yeah. Sure. Garlic am I crushing the garlic, or is it, like, garlic powder?

What am I doing? No. Crushing the garlic just for flavor. You know? It's you don't you can even take, you know, the the garlic out once the the pasta is there.

You know? It's just for flavor. Okay. Bacon in the pan. Yeah.

So garlic cloves. I'll put garlic cloves in Yeah. For flavor. I got it. And then the bacon, then the noodles, the egg yolk, and the Parmesan cheese.

And the Parmesan cheese and the and the egg yolk, you mix that before there. And then you put, like, all the yellow thing Got it. Pizza. And then you mix all that. How many how many egg yolks if I wanna serve 2 people?

For 2, I use 3. 3. Okay. Perfect. Yeah.

I got it. Yeah. See? Alright. So my pick this week is a big time waster.

I I found a channel on YouTube, and it's a guy that just sits there and records his playing, video slot machines. And his son and a friend are there, and they're doing commentary and jokes and things like that while they're doing these video slot machines. But this guy is spending, like, 300, 500, $750 per spin, and he's just sitting there and just tapping the button. Just tapping the button. Tap the button.

And he'll win, you know, lose No. He'll lose. 5 figures plus, you know, in just one setting or whatever. And I don't know. It just kinda interesting.

You know, you kinda like, like, you're sitting there in Vegas, you know, watching somebody, you know, hopefully win a whole bunch of money, but most of the time he loses. Of course, he loses. Yeah. Has he not checked the math? Yeah.

No. Evidently, yeah, he was very, very successful in business because he over the all the videos I've watched, I'm sure he's well into this 6 figures of losses and things like that. There was one video, he actually put a $100 in every spot on a roulette table and then found 38 people around him. It says, everybody's got a number. We'll spin it, and then whoever wins wins the, what, $35100 win.

So he actually spent more than the person won because the odds of winning are 35 to 1, but there's 38 spots on the table. So Yeah. Check the math, kids. Check the math. Yeah.

So, it's it's a channel called Vegas Matt, and, yeah, it's it's it's entertaining. You could sit there. Quite often, y'all I'll sit and, you know, jump ahead and try to find out where where all these special winter games and things like that that he's watching because his videos could be 2 or 3 hours long each one. So, it's interesting. It's just a complete time waster, but, yeah, check it out if you're bored and you wanna see somebody play, video slots in Vegas.

Alright, guys. Thanks, Dario, for coming on the show. Thanks, Mark. We'll catch everybody else on the next episode of adventuresin.net.