The Modern .NET Show

S08E06 - Testing Made Easy: Debbie O'Brien Explains Playwright and its Game-Changing MCP Server

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S08E06 - Testing Made Easy: Debbie O’Brien Explains Playwright and its Game-Changing MCP Server
The Modern .NET Show

S08E06 - Testing Made Easy: Debbie O'Brien Explains Playwright and its Game-Changing MCP Server

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

Debbie O’Brien discussed her experience with Playwright and its MCP Server. She highlighted the importance of keeping up with technology and not getting complacent, as new tools and features are constantly emerging. Debbie shared her own journey from being a JavaScript developer to becoming more comfortable working in .NET, citing AI’s role in facilitating this transition.

Debbie also discussed the use cases for Playwright and its MCP Server. She emphasized the need to test websites with natural language, suggesting that listeners take 15 minutes out of their day to explore these tools. The MCP Server allows users to input commands in a human-readable format, making it accessible to those who may not be familiar with programming languages.

The conversation touched on the importance of staying up-to-date with new developments and following reputable sources for tech-related content. Debbie recommended checking out her website, YouTube channel, LinkedIn posts, and other online resources, as well as joining the Playwright Discord server to stay informed about community-created content.

Debbie also emphasized the value of learning by doing and experimenting with different tools and techniques. She encouraged listeners to explore Playwright and its MCP Server, even if they’re not familiar with programming languages or web development. The goal is to become comfortable with the syntax and structure of websites, rather than relying solely on scripting languages.

Episode Transcription

It’s not just guessing. It’s not just saying, "oh, there’s something to log in. I think we’ll call the button login." It actually knows the button is called Login, it’s seen it. So that makes a big difference and makes it much more resilient. So that’s definitely a big change, right? It’s not just guessing. So definitely you should try it out.

- Debbie O’Brien

Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I’m your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.

Today, we’re joined by Debbie O’Brien to talk about both Playwright and the Playwright MCP server. We started with an introduction to Playwright, and talked about how both it and the MCP server for it can help you to automate both the writing and running of tests for your applications.

And that’s where the Playwright MCP comes In because it can automate a browser, it can basically go to the website, it can navigate, it can click, it can hover, it can do everything that you are doing in your tests.

- Debbie O’Brien

Along the way, we talked about how Playwright’s MCP server can help you to find test cases that you might not have thought of initially. As a perfect example of this while recording this episode, Debbie found a bug in the app that I use to record episodes of the show, and talked about how Playwright MCP would help to recreate and debug the issue.

It’s worth pointing out that we recorded this in early August 2025, and that AI quite literally moves very rapidly. Whilst Playwright and MCP servers are not likely to change too much between recording the episode an when it went out, it’ll be worth bearing that in mind as we talk about some of the AI stuff.

Before we jump in, a quick reminder: if The Modern .NET Show has become part of your learning journey, please consider supporting us through Patreon or Buy Me A Coffee. Every contribution helps us continue bringing you these in-depth conversations with industry experts. You’ll find all the links in the show notes.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : So, Debbie, welcome to the show. I am ridiculously excited that I’m getting to talk to you today because I’ve tried the thing that we’re going to talk about and I think it’s amazing, and I think more devs should try it, and we should be friendlier and nicer to our QA friends, and QE friends, and this will help us. So, first off, welcome to the show.

Debbie : Thank you. Glad to be here.

Jamie : Oh my goodness. So to give a bit of a spoiler, we’re going to talk about Playwright. And I wonder, would you be able to, you know, tell the listeners just a little bit about yourself. I know that you’re a Microsoft MVP. Sorry, I’m Microsoft MVP, you’re a Microsoft employee, working on Playwright. Like, what does that look like, and all that kind of stuff.

Debbie : Yeah, so I’ve been three years now at Microsoft and basically focused on Playwright. My job is to kind of build up the community around Playwright, listen to what people are looking for with regards to Playwright and how we can bring that feedback back to the engineers. And also like, how can people learn about Playwright? What is missing? What do the community need? So, I’m really focused basically on the community, but on Playwright. So, it’s very exciting and it’s a very cool job to have, to be honest.

Jamie : Yeah, yeah, being able to sort of reach out to devs at, I guess, different groups and And it’s open source, right?

Debbie : So it’s like, it’s not like you’re selling something that I need your money. It’s like, you know, you use it. I don’t make any money if you use it or if you don’t use it. So it’s like It’s just about sharing something cool. If you want to use it, cool. And if you don’t, well, that’s you. But it is cool, so use it.

Jamie : Amazing. Yeah, yeah. I think that’s a super fantastic place to be because baybe I don’t know, and I’m not asking you to say, but maybe there’s no pressure from people to say, “you need to get a million sign-ups and do 12,000 credit card numbers and all that kind of stuff.” So you don’t have to worry about that. You could just sort of, show the cool thing, be cool and see if people want to use it.

Debbie : I mean, obviously, we kind of like measure some metrics, right?

Jamie : Otherwise, it wouldn’t need me.

Debbie : But no, for sure. We need you to watch the YouTube videos. We need to download it. We need you to use it. But for sure, it’s a working on open source is fantastic. I’ve been in open source for many years, so it’s really it’s really cool. It’s like the best.

Jamie : Amazing. Yeah, we’ve got a bit of a open source… so we’re recording this in the summer, right?

Debbie : So we’re recording this well in advance.

Jamie : For the first couple of episodes of season eight, which started, I’m talking in the past about the future. So for those listening, it started in September. For Debbie, it’s starting in September. But we’ve got like a whole bunch of episodes about open source to start with because I’m like the whole world runs on open source software, right? Let’s talk about that.

Debbie : It really does. It really does. And people don’t realize that like, all these tools you’re using for free. We’re giving you all this stuff for free, right? Not just Microsoft, but many companies, many other, just individuals. That are just working on the weekends and looking for people to help and contribute and just give back. So it’s nice to. to be around that kind of community and also tell people, “hey, come on, work in open source, but contribute back to open source.” And yeah, it’s good.

Jamie : Yeah, it is. It’s awesome. As an open source contributor myself, but albeit to a very small library. Yeah, I’m always looking for people who can either contribute with something or check my homework, right? Because I don’t know if I’m doing it right.

Debbie : Yes. Yes.

Jamie : Okay, so let’s briefly introduce Playwright then so we can talk about it, because I realize we’ve talked a little bit about open source there.

Debbie : Sure. So Playwright, I mean, I kind of am wondering if there’s still people out there who have not heard of Playwright. Okay, so I’m wondering, are do they exist still? Because like in the last three years, when I first started at Microsoft Yeah, there was a very kind of small amount of community that were using Playwright, but not many. But we’ve seen the community grow so much that it’s absolutely insane.

So for those that have never heard of Playwright, you’re in the right place. But Playwright is about basically testing, and it’s about browser automation. So automating the browser to test for you. So that you don’t have to manually go to the website and click, and I remember doing this. And I think there are still companies out there that actually do this, you know, they like to hire somebody to sit there at a computer and literally just open a website, and click through it, and go through the things that the user is meant to have gone through, and see if there are any bugs, right? And that’s a manual process that is from the olden days when these cool libraries never exist.

But something like Playwright comes along and basically you write a test script That automates the browser, opens the browser, it clicks, it navigates, it hovers, it opens a tab, it does everything that you want it to do, so that that repetitive task of, say, filling out a form or putting something in a shopping cart can be done automatically without you having to do it. So you just have to write the test code. Well, you kind of just have to write the test code, but you could generate the tests as well because Playwright is so cool it gives you tools like CodeGen. So you can literally just go and click. And it will record that test script for you. And then you can just go press play, test runs, and you can obviously tweak it to add a few more assertions and things like that.

And then obviously, you’ve got AI, but we can talk about that a bit later. So there are many ways of getting tests written, but basically more people need to be testing. And Playwright is a very easy way for somebody who has never done testing before to just onboard and get testing into their application.

Jamie : Right. Because that was going to be my sort of first question about it. It’s like, “where does that sit in the modern dev setup?” Right. So we’ve got a team of engineers who may be software engineers, some quality engineers. We’ve got some you know, delivery managers, we’ve got our project managers and stuff. Where does Playwright sit? Who’s using it? Is it for everybody to use? Is it for devs, quality people, where where does it sit?

Debbie : Yes. You see, I’m a firm believer of whoever wrote the code and ships the code is responsible for what happens to it and where it should go. So if like obviously like, It depends on the size of the company you work for, the amount of people on your team. And I’ve worked for various companies. We’ve had QA departments, and we’ve had companies where we don’t have a QA department, and the developers have to write all the test codes. It really does depend. And that just makes it so easy because everyone can write it.

So you can write it, I can write it, the QA person, the developer, they can work together, whatever works for your company because it’s easy to learn, it’s easy for people to use. Yeah, there’s no reason why there’s no excuse, basically, to not write tests.

Jamie : Right. It’s a completely different type of testing, but I remember the promise of cucumber, and how that was like, “write your tests in plain English and some magic will happen and we’ll test your app.” Are we in that kind of land?

Debbie : I think we’re moving to that kind of land, but without the cucumber. You don’t need to eat cuc cucumber sandwiches anymore, I think. But you can use AI to basically use natural language to get tests written for you.

And obviously, you’ve heard of MCPs. So basically, you can you Playwright has an MCP server. And I uh you probably already have an FSA at MCPs, right? But I’m just going to quickly go into MCPs just very shortly because MCP is basically connecting the agent to the web, right, to do everything. What happens is that the agent can’t actually go and click on the website and do things that you want it to do. Now, I’m sure maybe it will in the future, but right now it can’t. And that’s where the Playwright MCP comes in because it can automate a browser, it can basically go to the website, it can navigate, it can click, it can hover, it can do everything that you are doing in your tests. When you’re writing those tests, well, you get the agent to actually just navigate.

So now you can actually use the Playwright MCP and just in natural language, just say, “go to this website, put something in the shopping cart and test the whole procedure And then write me a whole Playwright script that actually does that.” It’s pretty cool, like what it can do, which makes testing exciting. I’m super excited right now about testing because before it was like, “testing was boring back in the olden days.” I say the olden days, but I mean, like, seriously Testing was hard. It was very hard to onboard. And now testing is so easy.

I do think when it comes to AI, you need to understand a little bit what the test is doing. Although I think in the future people are not going to understand anything and they’re just going to get AI to everything and they’re not going to have a clue what went on, but they’re going to feel like they do and it’s just going to hope for the best. But I do think you do need to understand what’s happening to really ensure that it is a good test. But with MCPs, you can actually visually see what’s happening because it’s opening the browser in front of your eyes, it’s putting the product in the cart, it’s doing all the actions So you can just watch it and go, “yep, that’s what I wanted. That’s exactly what I asked for. That’s good.” And then you can write that test script in Playwright, or you could actually just write it in. natural language and then get it to run that again using the MCP. But that might become a little bit more expensive. That depends on the models you’re using and things like that.

So yeah, so many possibilities

Jamie : So, I guess with things like Playwright and MCP and stuff like that, you’re able to actually put into real life that old joke of, “QA engineer walks into a bar, orders one beer, orders twelve beers, orders minus one beer, orders NaN beer, orders string beer,” that kind of thing, right?

Debbie : Yeah, only I would never have come up with the none and the string, whereas the AI is actually coming up with that for you. It’s actually coming up with like things that you wouldn’t have thought about testing. You kind of sometimes when you go to test an application, you think about things and you say, “right, I’m going to test this, this, this and this,” or you have a user story, but you don’t sometimes think about the edge cases.

And AI is very good at thinking about edge cases. Because that’s a lot more experience than us. And it has all these kind of use cases that it’s gone through before. So it’s surprised me a hell of a lot where it’s like, “oh my God, I never thought about that.” Like in a search field, just putting in things like capital letters and mixed things and you know, mixing it all together. Like I say, NaN and strings are putting in numbers. What would happen if you search in the search field put in numbers? What does it tell the user? Things that we don’t think about all the time.

But some QA people do obviously think are very qualified and do an amazing job, and probably don’t need any tools at all. I don’t know. The years are few and far between. But yeah, AI can do a great job. Can also mess things up though.

Jamie : Yeah, of course, right? It’s a, you know, how do I put it? Back at Uni, when the lecturer that I had for programming languages was discussing the differences between managed languages and unmanaged languages, he used a rather grisly metaphor. He said, you know, C# and Java and managed languages like that are like using a chainsaw to cut down a tree, but it has a safety guard, so you can’t cut your fingers off. C, C++ and unmanaged languages, Assembly, stuff like that, they don’t have that safety guard. So you can cut your fingers off. And I think I feel like at the minute we’re in the

Debbie : cutting the fingers off.

Jamie : Yeah, we’re in that transition period between putting the safety guards on the AI and being able to cut our fingers off.

Debbie : Yeah, I think it depends on how you talk to the AI, what you’re looking for, how like prompting it is very important. but also understanding. And that’s why I said it’s really important to know what’s right and what’s wrong, because AI is very good at like, it’s just like my little kids, you know. It just thinks it’s done things right all the time. Like, you know, when you say the little tiny child, she cleaned their face and they like put the tissue at the back of their head and they’ve cleaned their face and they haven’t, but they’re so happy that they have, and they’ll tell you, my face is clean. You believe them or not. Right, you have to look at their face and see it, and then you have to look at the code to actually see it. And when you tell the AI, “that’s actually wrong, that doesn’t work. “It’ll just go, “oh, you’re right. I see now, I’ll fix it.” And then, like, you go, “no, you just deleted a line in the test. That’s not the right thing to do.” “Oh, I see, you’re right.”

Jamie : Yeah, one of my early experiments with lots of different models, my system prompts, I guess,, I make a point of saying, “I don’t want a sycophantic answer, I want you to take the gloves off and tell me the truth.” Which gets me about sixty percent of the way away from, “oh, you’re right,” and “aren’t you fantastic?” Because they’re quite like they’re designed to be like that. They’re designed to be like a positive reinforcement loop. But yeah, you have to be careful, I guess.

I haven’t used the Playwright MCP server, so I’m guessing as I’m going. But based on my experience with other tools, you have to be really explicit when you say, “hey, this test is broken, help me fix it.” Because otherwise, it will go, “cool, the test is broken. I’ll just delete it and that will fix the broken test,” right?

Debbie : Yeah. Well, with the Playwright MCP, it’s great because what it does is it actually navigates to the website and starts clicking, and doing all the actions and all the user story of getting from A to B, right? But because it’s done the actions itself, it’s got a snapshot of the actual page. So it can actually make a better judgment of knowing what’s in that page, what the HTML code is. It knows it, it can see it. And that makes it different. It’s not just guessing. It’s not just saying, “oh, there’s something to log in. I think we’ll call the button login.” It actually knows the button is called login, it’s seen it. So that makes a big difference and makes it much more resilient. So that’s definitely a big change, right? It’s not just guessing. So. Definitely should try it out.

Jamie : Yeah, definitely. Yeah, the… I’ve managed to create an HTML page that Playwright had gotten a little confused with, but I’d intentionally like I’d written some really badly formatted HTML intentionally to see if I could catch out, a friend of mine who’s training to be in QA QE QA. And it was like there’s a hidden field or whatever, and you know, some broken HTML, and they couldn’t figure out what the problem was.

And I said, “well, I’ll tell you what, right, you’re still learning. The tools are there to help. Ask Playwright to help you and figure out what the problem was.” And it came back with, “hey, you know, the HTML is broken and this field that shouldn’t be hidden is hidden. And that’s why you couldn’t do it,” which was really cool. It really speaks to that sort of snapshot idea.

Debbie : It helps you improve your code because sometimes it will find things. The test will fail, but the test is failing because the code is bad, and that you actually need to go and improve that code. And I found that a couple of times that something like CSS was hidden. And I was like, this is like because Playwright could see it, but we couldn’t see it, right? And it’s like, it’s there on the page, Playwright, it’s there on the page. I see two buttons. I’m like, no, there’s only one button. Oh, look, it’s actually there. It’s just got CSS hidden.

Jamie : Yep. And I guess that’s because, unlike a human with… how do I put it? I’m trying to think of the best way to put it. Unlike a human that has no site issues, looking at a screen, because Playwright is literally looking at the HTML in some instances. It’s able to tell you, “yeah, there are there are a couple of buttons here,” and “yes, you’ve applied hidden to it, which is why you can’t see it, but I can,” because I’m looking at I’m not I’m like okay, so here’s the question then. I’m just guessing, right? Is the question, is Playwright looking at the visual of the page or is it looking at the source code behind the page?

Debbie : It’s looking at so when it comes to like the MCP server, for example, it’s looking at this snapshot. It takes this page snapshot, which is a little bit similar to the accessibility tree of the page basically.

Jamie : Okay.

Debbie : So if you think about the the accessible tree, how it’s built, then it can kind of like look at the that’s why the get by roles are very important in play, right? Because it’s looking for those kind of roles.

Now when it comes to test IDs and things like that, obviously, it can see that. So Playwright itself can see the HTML, but the MCP server will use a tool called Evaluate JavaScript to see the HTML, see the test IDs and do that’s actually a new tool that was added very recently. Actually, something I did very kind of stupid, and cool, and funny But I basically got it to write a test and then put a big CSS red border around all the areas of the page it tests and then take a screenshot. Just to be cool. But it can do that, right?

So it can actually obviously has access to the HTML and CSS. It can go in there and modify it, right?

Jamie : Right.

Debbie : So it’s very cool.

Jamie : In that case, then, since it’s looking at the accessibility… I have a personal I don’t think “vendetta” is the right word, but I have some feelings about React, and how by default I don’t think that it’s very accessible because it divs all the way down. Does that mean then, just like high level silly question: does Playwright have a problem with React based websites because it’s a million divs rather than something similar to, as you were saying, like the accessibility tree

Debbie : No, so when it comes well, you see, you’re talking about two different things, right? One is Playwright and one is Playwright MCP, right?

So we’re just to be clear. So like you know, the Playwright MCP will be more towards the accessibility snapshot of the page, but it will actually almost take a smaller amount. It’s not going to be on par. So when you have all those divs, it’s not going to feed all that into like the context, because otherwise you’d be filling it up with empty divs. So you can’t really just take that snapshot, copy, paste it, put it in and just like say, “hey, too much area snapshot, it’s not going to work.” It will fail. So it’s not exactly the same. It’s a little bit different. It’s a little bit tweaked, I guess you could say.

But then when it comes to the actual Playwright without the MCP, just running Playwright tests, that’s not running against the accessibility tree. That’s going kind of more on the HTML So it doesn’t really care if you have seventy five divs. It’s just looking for that one button, that one element call with the roll of button.

Jamie : Oh, right, okay.

Debbie : And it can find it.

Jamie : Yeah, so it looks all right. Okay, yeah. So Yeah, that makes way more sense. Sorry, I got super confused then. But that’s okay. I’m allowed to be confused, but it’s my confusion, right? Not yours.

Okay then. So let’s say I’m writing some code. I’ve built some HTML. I want to use Playwright to test my I got a form Am I locked… so we’re we’re obviously we’re talking on a podcast about .NET. Am I locked to using .NET or can I use like JavaScript, or how do I interact with Playwright as a developer if I want to write a test?

Debbie : Yeah, so you basically choose the language that you are most proficient in, I guess or what your team is using, or some people choose based on what the the front-end of the website is built in. So you might have a React website, then it would make sense maybe for you to test in TypeScript and JavaScript. If you have a Blazor website, it might make more sense for you to test using Type… using .NET. And then if you have like, what’s it called? I don’t know, with Python, but you have Python and Java as well, right?

So They’re the four that we support. JavaScript, TypeScript, I call it, you know, the same. And then you’ve got. NET, you’ve got Python, and you’ve got Java. You can choose and there’s getting starter guides for each of those. Obviously, there are some missing features. TypeScript is the more feature-complete set I guess you could say. But that doesn’t mean that it’s missing anything specifically that you need if you were to write your tests in .NET. Just there are kind of some things that you have to do maybe more manually

Jamie : Okay. And I mean, that totally makes sense, right? Because you you presumably only have so many people on the team and it’s open source. And so if folks want to help out with filling in those small gaps, they can. But also there’s only so many hours in the day, right?

Debbie : Yeah, and we’ve had a lot of people from the community improving things and making those pull requests and adding some features and stuff that have been merged. So It’s been really cool to see what the community have done.

But yeah, we are a very, very small team. So a lot of people say, like, “why isn’t this available in Python? Why in. NET don’t we have this?” It’s like, we just cannot. So instead of like basically trying to spread too thin, we kind of like make sure the TypeScript one has absolutely all the features, everything, like the HTML report, the UI mode, the trace viewer, everything. But then a lot of things still work in. NET, like the trace viewer still works in. NET, perfect, still works in Python But UI mode doesn’t, which you might say, “why not? It’s very similar,” but it just doesn’t. I can’t tell you why. But that’s just something that you can’t use. But you can still use like the code generator tool. So you can still just generate your code in either of the languages that you want. But in TypeScript, we have the VS Code extension, but we don’t have that for. NET because most. NET people are probably in Visual Studio But yeah.

Jamie : Okay. A really, really silly question then. There’s this really a really old saying, and I don’t think it’s real Latin, it’s sort of fake Latin, “Quis custodiet ipsos custodes?” “Who watches the watchers?” So how do you all test Playwright then, since it’s a testing framework?

Debbie : With Playwright.

Jamie : Oh right.

Debbie : Yeah, we have actually thousands of tests. It’s really It’s really fun to see actually there’s so many tests. But yeah, we use Playwright to test Playwright.

Jamie : That’s awesome. Literally dog-fooding from the start, right?

Debbie : Yeah.

Jamie : So I guess then. Let’s just I’m going to jump ahead to a little bit that I usually do at the end of the episode. Let’s say someone is learning Playwright and wants to learn how it can be used they can just look through the Playwright tests for Playwright, right?

Debbie : Oh, totally. Yeah. Like literally. And some of them are really easy to understand, some of them are not. Some of them you’d be like, “what is going on here?” But in general, because Playwright is so kind of almost written in natural language-ish, you know, you can really read through it. It’s like, you know, go to Click, fill, type. Like you can just literally read along and you’ll understand more or less what’s going on. And then there are a couple of things maybe on the assertions, but the assertions are quite easy as well. It’s like to have count, expect something, to have count this, expect. It’s only when you add in the more complex things is when it’s like, “oh, what’s going on?” But in general, Playwright’s quite easy to understand. So, yeah, do kind of like roam around in any different repository that has Playwright and check things out

Jamie : Okay. So if I’m understanding correctly then, if we just step back a little bit based on what you were saying, if I want to create a Playwright Test, Playwright test script, whatever we’re going to call it. I just like I can say to it, not in these words, but I can say to it, “open the browser and go to this page. Click this button, fill in this field. Click this button, scroll up and down.” You know, like you’re saying, almost in natural language, right? I could say, “do this, then do this. And wait for this thing to happen, maybe wait for this page load to happen, wait for this Ajax request to complete,” that kind of thing?

Debbie : So yes and no. Again, two different things. And we kind of have to separate it so that people understand a little bit better.

So you’ve got Playwright, which is the test runner, for example. That’s in the JavaScript world. But then in. NET you have a different test runner that you would use. So using Playwright as a library, and you’re using XUnit or whatever test runner you’re using. And in that scenario, you can open up a tool called CodeGen, which is a code generator from Playwright. And that opens up a browser, and you put it in the URL bar where you want to go, and then you actually click, manually click it. And as you’re clicking, filling, typing, doing whatever you’re doing, it’s writing the code for you. So it’s every time you click, a line of code is written. Every time you click, a line is written. And you can write assertions and generate assertions as well, but not all the assertions are available. So you do have to do some tweaking and add some other assertions maybe later. That’s a really good and easy way to get started.

Now if you’re talking about AI, that’s a different product, but it’s still Playwright. It’s called a Playwright MCP. And that’s in your say, I’m going to say VS Code here, but you could also use it in Visual Studio. But in VS Code, you go to agent mode and you basically make sure you have the Playwright MCP installed. You don’t even need to use this in a repository that has Playwright. So you could use this in any repository you want. And you basically make sure the Playwright MCP tool has started. And then you put in your natural language, “go to this website, click on this, do this, do this, do this,” in your natural language. And then you have to tell it what you want it to do because now it has no idea what you want. So you might have to say, “generate a Playwright script from that.” So that’s basically using the Playwright MCP, using the AI side of You merge the two of them together and you’ve just got like endless amount of fun when it comes to testing because you can literally do anything and everything with any language, and it’s very cool

Jamie : Right.

It’ll sound like a really silly thing to say, but I like the idea that I can point it at a website without there being any kind of Playwright component on there or Playwright component in the source code. I could just say, “hey, Playwright MZB. Here’s the source code for my website. Do the I will start it, or maybe I can tell you how to start it. Do this thing and test that this thing exists,” right?

Debbie : Exactly.

Jamie : I can then do like a a guest test, I guess, for a repo that I don’t own, but that exists somewhere, right? I don’t know why people would do that, but I can do that, right?

Debbie : Well, I think not everyone has access to the source code when they’re asked to test something. So maybe, you know If you don’t have the source code, you need to be able to test the website. How do you do it? And using the MCP, you can do that.

t’s kind of also good sometimes because if you don’t have access to the code, it can’t actually guess and say, “oh, I see there’s a button there.” It actually has to go do the work and then really figure it out. But if you then if you do have a big, massive project that’s using different kind of fixtures, palms, all that kind of stuff, and you have the code, then it can kind of like see has a big a bigger story, so it can kind of maybe do a better testing architecturally wise, right? But that just depends.

But the good thing, and this is really cool: you can also use the Playwright MCP to ask it to go to a website, any website. So if you have your own website, Jamie, you can say, “go to mywebsitecom and give me some ideas of things to test.” Like, maybe you don’t even know what to test. You’re not going to tell it to go click here and do this because, also, like, I sometimes have no idea what to test. So you just say, like, “can you just go to my website and give me five features of things that should be tested?” And it will go there and it will say, “oh, I see there’s filtering, that’s a really good thing to test. That should be tested. Oh, yes, we’ve got dark mode. Dark mode is another thing.” And then it can kind of give you the five features and then you and then it will say like," you know, do you want me to write the test for you?" Or and you can say, “no, actually just write the three of them,” or whatever.

So I do this a lot in demos and I limit it down because also not to kind of give the AI too much to do because then it can kind of get lost. But also because it makes it quicker in demos to actually just show one or two or three things. But it’s really powerful and it’s given me ideas of things I never even thought about testing. I was like, “oh my God, I never thought to actually test that.” It’s like it’s funny, right?

Jamie : Yeah, yeah. Um, I was watching a video earlier today of uh you using Playwright to test your website and like, go to this page and filter all these things.

Debbie : Yes.

Jamie : That was really cool. Remembering that video just now and you talking about it just now gave me the idea. Hey, listener. If you’ve got access to Playwright MCP, head over to the website for the podcast and try out the search function and see what happens right. There is a search function. See if you can get it to break. You probably can because I wrote it.

Debbie : Exactly. And remember, the Playwright MCP is also open source and free. So basically, like, you know, once you’ve got something to be able to use an agent, so Copilot, for example, and you can use it with the included models now. So basically, you have no excuse. Just start getting it to just test websites. Possibly test your own. But if you feel like testing other websites just for fun, totally go and do that.

Jamie : Absolutely. Yeah. Folks, go ahead and point at the website for this podcast, for sure. I think there’s nothing you can break on that because it’s a statically generated website, so you can’t…

Debbie : Well, you can’t do damage, but but you could definitely find things that don’t work, which is a different different thing.

Jamie : Amazing, amazing. Yeah, so go go find me some issues with the website, please, and then use the contact form to tell me what they are. So I can go fix him.

Debbie : I just make a PR, no?

Jamie : Yeah, yeah, that’s it. Awesome.

Jamie : So, we’ve talked about both Playwright and Playwright the MCP server portion. And I’m worried that since I’ve asked questions that lead across both, I may have led to some unintentional confusion So just to check my understanding, then Playwright is a library I can use, if I’m in. NET Land, Playwright is a library I can use with a test runner such as XUnit or NUnit or MSTest. And I can use Playwright to watch me interact with a website to then write the code to run that test. And then I can say, “go run that t And just run it in XUnit, just run this test a thousand times and make sure it doesn’t break,” and it shouldn’t do, but there you go.

Debbie : Exactly. Or you could totally just write the code yourself if you don’t want to click around and do things if you’re very good at you know, writing code and writing test scripts, then you can just literally stay in code land. You don’t have to actually open the generator tools. They are given to you as a help. But you might kind of say, “no, I know what I’m doing as I’m building and I’ll write it.” And yeah, then you can run that test and you can run obviously your tests on CI, which is obviously running it in development mode is also good, but making sure that they run on CI on every pull request That’s the kind of beauty of it, right?

Jamie : Yeah, okay. So then again, to check my understanding, I can open up a test class. Maybe I’m using XUnit, and I can start a test that I can go. I’m going to make some stuff up here, but I can go, “Playwright. go to website. Playwright dot click link, Playwright dot enter username or something like that,” right? The the words will be different, but I can say Playwright library.

Debbie : Yeah, just not not Playwright dot, but yeah.

Jamie : Okay, cool.

Debbie : And the the thing to mention as well when it comes to Playwright tests and one of the things is like Playwright auto waits For things to appear on the page, so you don’t have to think about like how long is that gonna take that button to appear? Because it’s got some sort of CSS animation. You know, there’s no way Playwright will just wait for it, Playwright will go, “I’m going to wait until this button appears because I know that the user wants me to click it. I’ll wait for it to appear and it’ll wait and it’ll wait,” unless it times out because the button is not there, right? But that’s really important. And the same would like assertion. So once you make sure you’re using the correct Playwright assertions and not just general assertions, there are things to watch out for. But that’s the beauty of Playwright, and that’s why it’s the tests work because we have all that built in, which makes it super cool.

Jamie : Right, right. ‘Cause that was going to be a question that I bring up in a moment when I ask about Playwright versus Selenium or Selenium. I’m not sure how you pronounce you pronounce it. But like I remember using an early version of Selenium, and I would have to artificially add waits. Like, “load the page. Now wait for twenty seconds whilst all the animations happen and all of the wonderful User interface flashiness happens. Now click the button. Now wait again.”

Debbie : And then you’ve got all these waits, and then your test takes so long, and you wonder, why is it taking so long?

Jamie : Yeah, exactly. And invariably, you make it wait for too long. Right? Because on your machine, when you first ran it, it took twenty seconds to do the animations, but really, it maybe only takes fifteen or ten seconds to do whatever it needs to do.

Debbie : Or the other way round and then it fails because of like you put the wrong timing in.

Jamie : It sounds like we have similar experience. Yes. Okay.

So related to that then Let’s say I’m evaluating technologies. I’ve got Playwright in one side, Selenium in the other, and I appreciate you’re on the Playwright team; but like, is there a difference? Are they effectively the same thing? Is one a fork of the other? How do are they related? Like, what what’s what’s the story there

Debbie : Well, definitely no relation. I… to be honest, I haven’t used Selenium in many, many years, but my belief Selenium, from what I know, is Selenium is still very excellent path driven, CSS kind of driven, which means you’re basically using where the button is positioned on the page to be able to find it. And that’s really kind of in our use case in Playwright is very flaky because. In the frontend, especially, we change your website so much, we change your CSS. We’re always moving things. So if you move that button in that position, when you’re using xpath, your test is just going to break. Or if you update your CSS Your test is going to break because it relies on the CSS. And that doesn’t make sense because a test should not rely on the actual HTML. A test should be more focused on what the user sees. Closer to the user. And that’s why we call them user-facing roles, like get by role, because that’s what the user sees. It sees, or an accessibility kind of, you know, a screen reader would read out. So get by role button, right? Instead of a div div span button or something, right?

So they’re kind of things to be very important. Playwright is basically more modern, and I think that helps a lot in how it’s built because when you’re the newest I guess, even though it’s not like new that now it’s old at this stage ‘cause it’s like more than four years. But when you’re the newest, you’ve learned from the mistakes of all the others, so you can actually make a better product. And I think the person who always creates the first one is always great at that time, but it’s always going to be the worst one later on in life. And that’s just the way it is. But yeah, they’re very different. I think for me, Selenium was very hard onboard And there’s a lot to kind of learn and understand, whereas Playwright is very, very easy to onboard. And I think in our world today, that is super crucial, developer experience and easy onboarding. Otherwise, you just lose people, they go to the next product straight away.

Jamie : And that totally makes sense, right? It’s about the ease of adoption. If, for the same reasons you just said, developer experience. If it takes me two hours to get started with something and I’m having to do a whole bunch of setup that I don’t like, and then I then don’t ever have to do it again. And in six months’ time, I onboard someone onto the team and I have to go through the same several hours of pain and re-onboarding. I’m not going to want to do it. And so make that super easy. No, I really appreciate that.

But they still sort of… I guess Playwright still achieves the same goal, right? Of still I want to test my app.

Debbie : Exactly. You’re still trying to test. a website, exactly. And all of the testing tools, the idea is to test a website using the browser. And it’s funny because we’re years and years and years trying to get people to test websites. And like we improve the tooling, we improve everything, but not enough people are still testing their websites. So we’re not winning the battle.

Jamie : Look, I made it super easy. Just do it, okay?

Debbie : Yeah, exactly. You have no excuse.

Jamie : Okay. So then. I have a website I want to test, I can use Playwright. What if I have an API? Can I do that too? Or is it just for frontend what the user sees

Debbie : Yeah. So we do have API testing as well. It’s not exactly to the extent and level of, say, swagger and things like that, but you can still do API testing.

So I have it on my website on my website. No, on the the movies website that I have. And there’s a couple of API tests in there, just some very basic ones. You could totally check it out. It just, you know, yeah, it’s.

Some people do a use it a lot, actually. Some people and some companies are really just totally invested in Playwright and doing their API testing there as well. And I think that’s also because if you’re writing tests in one library and stuff, then you have to go and do API testing somewhere else. It’s just like a lot of context switching. Whereas if you can have it all in the one, your whole team just needs to learn one thing. And then they just do it. So again, it depends on what you’re looking for and what you need. But yeah, it’s pretty… you can do anything. You can do anything with Playwright. You can even do component testing. Like seriously. You can you have no excuse.

Jamie : Just get it tested, folks.

So, what I’d love to do, if that’s all right, is I’ve got some questions from a colleague of mine who is a a QE. She’s a lead QE, so she’s you know, she really knows that stuff. Not that non lead QEs don’t, but I just wanted to call that out. Anyway, yes, so a couple of questions from this particular colleague of mine. And I was wondering, would you mind giving me, if you can, an opinion on like your answer as an opinion rather than this is a Playwright thing?

Debbie : Okay.

Jamie : So they’re all around AI and MCP.

Debbie : Oh, lovely.

Jamie : And we could totally cut this if if you. are unable to answer for whatever reason. But the first question that they have is, “with the creation of MCP and Playwright MCP server, do you think a traditional QE QA role is shifting more towards a testing strategy and AI prompt engineering rather than spending time drafting how to test something and writing the test scripts and all that kind of stuff?” Is it more are we all moving towards prompt engineering, in your opinion?

Debbie : In my opinion, I think everyone is moving towards areas that we are very unsure of where we’re going because we’re unsure of the capabilities. But I do believe that we need to be more proficient in our like, and I don’t mean people are not doing their jobs. I mean, we need to be able to get things done faster, get more things done because there’s so many websites out there that need to be tested and you cannot do it all. So using and leveraging AI to do it, because we’re going to start creating a hell of a lot more code with all this AI generated stuff. So we really need testing, and testing is now even more important. And overseeing those tests, I think we’re going to start overseeing agents to ensure that they’re testing. That’s kind of being moved towards that role.

But I think it’s I think everything is changing, and I think we have to embrace that change because if not, life would be boring if it didn’t change. We have seen so many things. I mean, I didn’t have a mobile phone when I was a kid. They didn’t exist. The internet didn’t exist when I was a kid. Imagine being scared. Like, I remember being afraid of somebody FaceTiming me with a video, like, that you could actually see them. I was like, “oh my God, why don’t I move my pyjamas? And I answer the phone and they’re going to see me. Like, that would be, oh my God,” right? I thought that was the most terrible thing in the world. And now it’s like I mean, I use it all the time. We live with like, you know, video calls. So I think we just have to understand a little bit in our role what AI can do for us. leverage that and do an even impressive, more impressive job.

But yeah, I think we will be doing less of the boring, mundane tasks. And just using our creativity a little bit more and using our leadership skills a little bit more, because we’re going to be leading these agents and overseeing them for sure.

Jamie : Yeah, and that kind of makes sense, right? Like when… I think it was back when ChatGPT 3.5 first appeared, I started telling people that, you know, the AI because I didn’t know that agentic workflows were coming ‘cause, you know, I’m not clever and I’m not prescient. But I was telling people that, “hey, it reduces the toil, right? If it would take you 45 minutes to write out some code for something, and then spend some time to think about the edge cases, and then write tests, and then everything else on top of that, the typing isn’t the hard part, right? We’ve solved that problem. And so getting the computer to type it for you faster, as long as you are telling it what you want it to do and you are covering all of those edge cases and then using it as like a pair programmer or a peer to help you cover up those edge cases."

I totally agree. I think Yeah. Like, you know, the wheel is doing pretty well, right? That caught on, and we’re okay with that.

Debbie : Well, Jamie, I remember like writing code before editors existed. And that’s how we wrote code. And if you forgot a comma or a a you know, a bracket or any of those parentheses, you were just stuck searching and staring at a screen for ages, trying to find that missing one, or question mark in PHP back then, right? Those have been fixed. We can literally just use editors. It just fixes it for you, just right in front of your eyes. And nobody’s complaining about that, right? Like, did you want to sit spending hours looking for that missing comma? No, that’s a waste of your time. So why do it?

So we just have to think along those lines that things are changing. But obviously, it is scary times. And I do understand. And I have to say, like, yeah, like we don’t know where we’re going. That’s exciting, but also scary because we’re opening doors and doors are opening very, very fast. And it’s super exciting. But obviously, I cannot predict: will I still be Microsoft in five years’ time talking about Playwright? Who knows? I have no idea. But right now, I’m having a whale of a time

Jamie : Yeah, a hundred percent. Yeah, I agree. So what you said there about um writing code without an editor, back at university when I did my CompSci degree, the first month of lectures were: the lecturer got up at the front, had their lectern, plugged their laptop in, opened up Notepad and would write the code, and then use the C# compiler executable to compile and run the code, right? So he was doing it without an editor. I mean, Visual Studio was a thing, but he was like, “I’m not teaching you Visual Studio, I’m teaching you. C# and .NET.”

Debbie : And it’s the best way to learn. Like, I feel like my skills are so good because I learned how to code constantly just writing it from scratch. And I did fail also to learn to code because of the same system, because I tried to upskill, and I tried to learn JavaScript and it was at O’Reilly School of Technology, and there was literally everything was true email, and email was the only technology really we had to be able to talk to someone on the other side of the world to help get them to correct their homework. And like when you were stuck, you would email the teacher and the teacher would say, “you’re missing a comma on line forty five,” and two days later you receive that email and you go, “ah, now I can get back to fixing my code.” And, like, that was a ridiculous way to learn, but that that existed, and that you know, we’ve come a long way from that.

So, people learning to code nowadays have it super easy, and that’s why you know, sometimes it’s like, “oh, they’re just going to like come in and just, you know, vibe code everything and not understand what’s going on,” right? And is that okay? But I don’t know. Is it? It totally depends because there’s a lot of creative people out there who are not coding because they found it too difficult to learn. I almost gave up and I might not have been here if I hadn’t have just pushed forward and I really, really struggled, but I really had to like do it. But a lot of people have left coding industry because it takes them so much time to learn to get to the, you know, to the stage of being job ready and stuff. And now they can come in a lot you know different. It’s different to the entry point is different.

But the skills can also be different because I think this we’re going to see a lot more like architectural style, creativity style designers, they do a better job at designing a website, but they can actually maybe use tools like GitHub Spark is one of them, where you can actually get it to write the cod for you and just give it your ideas and like say, “I want this. Here’s a design, go and create it.” Like that’s so cool. I think it’s brilliant. I just love how where AI is taking us.

Jamie : Totally, totally. And it helps with how do I put it? Like spellcheck, right? When spellcheck first came out. That didn’t stop people from becoming writers, right? It didn’t stop anyone from being an author. It just meant that it was easier to spot when you’d made a typo. I know I’m conflating too completely different technologies here, but like too completely…

Debbie : But I’m literally doing that today, right? Because if you look at the Playwright docs and if you read them today, they are written how I speak. And I speak very good English, but I write like I speak. I’m not a good technical writer. I’m not trained to be a technical writer. It’s not my skill level. I’m just not good at it So I will write docs that you understand, but they are written in a way if you read it, if you’re maybe not natural English, it’s not your first language, you might kind of read it and go, “what is she saying?"

And I have literally just got AI today to go through the Getting Started guide and just fix it. And it’s corrected my grammar. And I actually used to teach English. That isn’t that sad that AI. He’s literally saying, “all those people you taught English to. Like, it’s different teaching them.” But seriously, AI is doing that now. Do I want to be going and adding Oxford commas in here? I don’t care where the Oxford comma goes. That’s not in my interest to know that. So AI is actually doing I’m using, yeah, I’m using AI right now to actually just fix all the pages in the docs, and you can go to that Repo, and you’ll be able to find pull requests on this over the next few days as I improve the documentation. And that’s going to help a lot of people. And that’s all thanks to AI. I think that’s pretty cool.

Jamie : It is. It is. And nobody complained when, you know, adjustable wrenches or adjustable spanners were created, right? It just it makes life easier.

Debbie : Yeah.

You know that moment when a technical concept finally clicks? That's what we're all about here at The Modern .NET Show.

We can stay independent thanks to listeners like you. If you've learned something valuable from the show, please consider joining our Patreon or BuyMeACoffee. You'll find links in the show notes.

We're a listener supported and (at times) ad supported production. So every bit of support that you can give makes a difference.

Thank you.

Jamie : But so the other question that they’ve sent through is for those who are writing tests and working with testing things like Playwright, with MCP, with things like that: in our increasingly AI driven world what skills do you think that a that a good that someone who wants to become a good engineer of any kind, software engineer, quality engineer, whatever what do they need to be able to learn? Is it just like learn how to interact with a large language model of choice or prompt engineering, that kind of thing? Or is it more like, “you will still need to know how to do the underlying stuff, but you need to start here,” right? What skills do you think that QEs should be looking at

Debbie : That is the million dollar question. It’s like I don’t think I have the answer to it. And I don’t think anyone has the answer to it. But I can give you like my thoughts right now. But maybe in October when this is released, my thoughts could be completely different because something else is just like has been released and things are changing so fast.

So I think at the moment, it’s trying to keep up with AI, trying to keep up with technology in general, which is hard. I’m struggling to just keep up with all the things that are out there. So playing and testing. I think it’s really important to be able to use the tools to build with them. So for example, I’m building with GitHub Spark right at the moment. This is a it’s in Public preview. It’s not fully out and available to everyone yet. So I’m getting to play with it, which is really cool. Some people have access to it. And it’s basically just, you know, creating websites using AI, just fully using AI. So how do we do that? How do we get it? How do we tell it what to do? What is the right prompt, as you said? Is it just about prompt? Is it also about context? Is it about spec driven? There’s a lot of different things. So you have to be able to understand, “with that tool, how do I get it to do the job I want I want to be done?"

And the only way to do that, it’s not like you read a book. It’s not like you can’t go to university anymore and just like, I’m going to study AI And I’m going to come out in a year and I’m going to know everything and get a job. Because in a year, AI has changed so much that whatever you studied is just changed. So you really have to be on top of things. And I think YouTube is absolutely amazing. There are so many videos on YouTube. And we at Microsoft have released so many videos on AI and so many like dev days on MCP. You can like catch I’m still catching up on them actually. But definitely YouTube, you can learn for free. That is the most amazing thing ever. I paid thousands and thousands and thousands of Euros to learn JavaScript. And I you know, it was worth it in the end. But now you can just watch YouTube.

And there are obviously other ways and stuff, but you have to learn by doing. You have to try things, test things out, play with things. And then you’ll get a better understanding of what works, what doesn’t work, what goes together, what you can do. Because what I do and what you do, Jane, you’re totally different. And we’re going to have a different perspective and different way of looking at things But I think it’s very exciting. I think somebody knew there’s so many different paths they can go down. They just have to actually take the step and go down them.

Jamie : I agree. I agree with that. You don’t get into technology to stop learning, right?

Debbie : No.

Jamie : You get into technology because it’s exciting, there’s a new thing to learn, and maybe you won’t get to the point where you know it all.

Debbie : You’ll never know it all.

Jamie : Yeah, exactly, right? But you’ll get to a point where you’re comfortable with, “oh, there’s this new thing I can apply my knowledge from the previous thing to this new thing, and I get it, and I can use it, and I can move on.” It’s not a case of, “oh my God, there’s a new thing, and it’s really scary!”

Debbie : No, and you know what the exciting thing is now as well? I’m basically more a JavaScript developer. That’s what I’m good at. If you were to throw me into a. NET project a year ago, two years ago, I would be like struggling. I would be like, “oh my God, I don’t know what to do. This is so scary.” And I’m like, “I’d have to study so hard to try and keep up and try and, you know, keep that job,” right? Whereas now, if you threw me into a .NET project I’m pretty confident I could get do a good job. Even though I’m not a . NET developer.

I’m not putting down. NET developers and saying I don’t need to know. NET, right, or C#, whatever. But AI helps us so much that it the syntax isn’t important anymore, but the actual architecture and the structure is really what we need to understand and improve and learn

Jamie : Yeah, absolutely.

So my thing is, and it may be down to the fact that I focused on CompSci rather than software engineering at Uni So I studied like languages and how they all fit together and stuff like that. It’s never been the syntax. My friend Zac always says: “if you write an if statement in one language, it’s going to look like an if statement in another language. It might be a little bit different, but that It’s not that bit that changes. It’s the language-specific features.” So, like…

Debbie : What does the if statement do?

Jamie : Yeah, right. Or maybe the language-specific libraries that you’ll use, or the paradigms that you’ll use in that language. So, for instance, you know, writing Pythonic. NET won’t work and writing .NETish Python won’t work, right? You need to switch the mindset around it. It’s not really the language.

But no, I also appreciate what you’re saying about you can use the AI tools to help you to sort of transpose, transpile from one to the other. “Hey, I know how to do this in JavaScript and I need to write it in C#. How do I do that?” Splat, right? Nobody really complained when Google Translate or Bing Translate came along, right?

Debbie : Yes. Translate the menu so you could order a beer in another language.

Jamie : Amazing. Debbie, I have had such a fun time chatting with you today. I really appreciate you spending some time with me and the listeners. I, were going to have a little disclaimer at the beginning of the episode saying, “hey, you know, we’ve recorded this super early, so the underlying AI things may change. But, you know Playwright itself is a really cool thing you should go check out and go put it in your favourite website and test the website. You can’t do anything destructive, so don’t worry about destroying things, but just test the website and see what happens.” And then, you know, if you have the ability to check out the MCP server too, because then you can test a website with natural language. “hey, go to this website and try this thing,” right? Why not?

Debbie : Exactly. You have no excuses. 15 minutes. Just take 15 minutes out of your day and go and do that.

Jamie : Yep, absolutely. Absolutely.

So, I guess for people who are listening along and they’re like, “I want to find out a little bit more about what Debbie does.” I know that you’ve got a website, so we’ll link to that. There’s a bunch of courses on there and blog posts and all sorts of stuff, and YouTube videos about how to use Playwright to do some stuff. Is that the best way for folks to find out what’s happening? To go to the go to Debbie’s website and then maybe go to the Playwright website?

Debbie : Yeah, definitely. And follow me on LinkedIn. I post a lot of stuff on LinkedIn. I find LinkedIn is a great way For sharing tech stuff these days. So that’s kind of like my go-to. So if you’re just like, you know, if you’re using LinkedIn, you’ll probably see posts and stuff by me.

Or if you’re starting, definitely the docs. We’ve got some great videos in the Playwright YouTube channel as well. And then my website obviously has some other extra bonus material in there of things I do on the weekend. But there’s so many others, I could actually just write a whole list of like other people to follow and other things. So I would say just kind of like as you’re kind of going along, find people that like are writing good articles and then follow those as well. It’s like not just me, don’t just learn from me. There are other people out there doing great content.

We have a Discord server as well, so you could totally join that and you’ll see all the blog posts and videos that the community are creating, the ambassadors are creating. So there’s a lot of, there’s a lot of content out there.

Jamie : Amazing. Amazing. I’ll collect a bunch of links and put them into the show notes, folks. So, if you’re listening along, press on your player of choice and all the links will be there. Or if you’re on the website and you’re reading the transcription, scroll down a little bit. They’re right there.

Debbie, it has been so much fun talking with you today. Like I said, I really appreciate you being on the show. Thank you ever so much.

Debbie : Thanks everyone for listening.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places