Epic Web Conf '24 Speakers

Artem Zakharchenko

Software Engineer, Czechia

Watch Talk


  • Thursday, 2:00 PM2:20 PM
    Mocking WebSockets with MSW


Artem is a software engineer passionate about API design, testing, and open source. He's the author of Mock Service Worker, Egghead instructor, and technical writer. Oh, and he loves coffee!


share on twitter


Hello, everybody. I'm so excited to introduce to you my friend, Artem. And Artem, you're going to have to pronounce your last name. I've tried it before. We've done podcasts together before, and I did not do a good job. No, actually, you did a fantastic job last time.

Okay, I'll see if I can do it. Zakarin... no, no, no, Zakarchenko. Yes, yeah, that's right. Yeah, Zakarchenko. Yeah, Zakarchenko. Yeah. Well, so, Artem, can you introduce yourself to folks a little bit? Get them excited to meet you at Epic Web Conf.

For sure. Hey there, my name is Artem. I'm a software engineer based in the Czech Republic. I'm passionate about testing, API mocking, API design, and web standards. And I hope that I will be talking about those on Epic Web Conf.

Awesome. Yeah, so why don't you tell everybody about what you do for your day-to-day? Typically, I would ask about your job, but I know that your job is kind of unique, so why don't you tell people about what you're doing?

Yeah, so a couple of months ago, I decided to switch from a full-time job and basically focus on educating people. I wanted to share more what I know about testing, so I joined with Kent, and I am a part of the Epic Web team right now,

and I'm working on my first workshop, which is going to be focused on fundamentals of testing. It's been quite crazy, and my day-to-day routine is different every day, so I'm trying to basically balance between working on the workshop, articles, videos, and also doing some open-source work.

And it's looking really cool, and I hope to share more of those things this year and hopefully years to come. That's awesome. It's a very familiar story for me. I remember doing that very well, and it's been awesome.

So I do hope that you enjoyed that and that it pays off well for you. And one thing that you're doing that I never did was actually work on getting sponsorship for your open-source so that you can actually justify the time that you're putting into that.

So that has been awesome as well. Yeah. So the open-source project that you work on primarily is MSW. Can you give us a brief history of what that is all about and why people should care about MSW? Yeah, so MSW, or Mock Service Worker, it's an API mocking library,

so it basically allows you to capture requests, observe them, and if you want to respond to them with particular mock responses. It's becoming to be quite a long-lived project at this point. I think it's like six years old now. Wow.

Yeah, it's crazy. Time flies really fast, especially when you work in an open-source. And it's become more and more used. It's almost a de facto choice right now when you're trying to mock APIs when you're testing or developing JavaScript apps. And I think it's really great. I hope so.

I'm being very lucky to get a lot of feedback from a bunch of people all over the world, how to improve it, how to make it better, reporting bugs, and everything around it. So we finally arrived at this huge monumental change last year, which was MSW 2.0,

which brought the whole library and the API mocking experience closer to the platform. So people are working with requests and responses as they would normally do that in JavaScript. And I think it's a fantastic move forward. Yeah. Yeah, I'm definitely a huge fan of that.

The closer that all of our abstractions can be to exposing platform APIs rather than wrapping them with their own bespoke APIs, the more shareable our code is, the more shareable our knowledge of the code is. There's just so many benefits to getting closer to those standards.

So yeah, super huge fan of what you've been doing. I'm one of the early adopters of MSW and really happy about what MSW has been doing over, I can't believe, six years. That's wild. Oh, yeah. Cool. So with the interest in testing,

the workshop that you're putting together, what is it that has gotten you so fascinated by testing? I mean, mocking API calls and stuff, that's one part testing, but also partially development and stuff as well.

So I suppose MSW might have some part in your story of why testing is important to you. But yeah, let's hear a little bit about that story. Yeah, so it's maybe a little weird, but I got into testing by fearing testing a lot

because I never studied anything computer science related in my life. And when I got to seeing these first tests in the wild, I was really scared of those. And I didn't know how to write them, and I tried to avoid them and push this task to somebody else. But then somehow, and it's really hard to pinpoint,

but over time, I tried to write a test, then I tried another one, and then I tried testing a bunch of different stuff. And somehow years later, I arrived at this point where it's not scary, it's essential. It's like you approach things from your intention standpoint,

what I want this code to do, and then very often you just put that intention into test. And so I decided to get all that experience and maybe share it a little with people and also learn. I already learned a lot just by preparing to these workshops, and I hope to learn even more in the future.

Yeah, you said a couple of things that resonate with me a lot. That last thing that you said, you learn a lot by preparing the workshops. That is so, so the case. Especially early on in my career, but even still, my secret to learning and acquiring knowledge

is by just sharing the knowledge that I acquire as I do that. And I think that just solidifies your understanding of whatever it is that you're learning. So yeah, super agree with that. And then also just the incidental experience with testing, like the more you do it, the more you do it.

And then you suddenly develop these opinions, and all of a sudden you can have a conversation with somebody or write articles, which you've done. I think you've done three or four articles now on Epic Web. And all really good articles in their own right.

So I'm super jazzed to have you as part of the team on Epic Web producing material on testing. I think you're doing a fabulous job and super excited about what you're going to be doing there in the future. So at the conference, of course, as I was putting this conference together,

I'm like, well, I definitely want to have Artem there. And I expect he'll probably want to talk about testing. What are some of the things that you're thinking about for what your talk will be at the conference? So it's not decided yet. So it's going to remain a bit of a secret. But there are a couple of topics that are flying around.

So first one is related to this recent movement to React server components and this paradigm as more and more frameworks can adopt it. Naturally ask the question, how are we going to test that? And I may have some ideas about it. I have an experimental API developed as a part of MSW

in this context, focusing on the network parts of things. So we kind of establish the proper boundaries in tests, even when we're testing React server components. So I think this is a really cool approach and I would love to talk more about it. If I get it to the point that it's worth sharing, then you will absolutely hear about it one way or another.

And I have a couple of other cool ideas like tackling some of the long lasting issues with MSW. So it couldn't properly run in parallel tests because it introduced a shared state of handlers that leave outside the test. That's the whole point of MSW. It's like a standalone layer of your network description

that leaves on top of everything else. But it had some side effects as well, like the shared state. And so when a bunch of tests run in parallel, suddenly one test can say, if you fetch the user, then respond with an error. And then another parallel test tries to fetch the user and expect successful response. That's been quite an issue.

And I think that I arrived at the way to solve that. And I really love the solution because it uses just standard Node.js API. So once again, if you're hitting this, I'm using the standard. It's probably a good direction. So I will gather more feedback on that

and definitely share and keep people updated. And there's also one more thing, probably like very early to speak about that, but I had some progress on WebSocket support in MSW. And this will be huge once it lands. And until then, yeah,

I'm just gonna keep people on the tip of their seats. Yeah, awesome. Yeah, that's definitely, I know that that's one that has been long requested and definitely needed. There's not a solution for the mocking WebSockets as actual WebSockets at all.

The only solution you can have is to mock the modules themselves, which I know that you have a lot of thoughts on mocking modules instead of the network requests, which we don't have time for here. But the last thing I wanted to ask about or make sure we mention is the workshop

that you're gonna be giving on site, in person at the conference as well. Do you wanna tell us a little bit about that? Oh, for sure. So basically I spent the last couple of months working on this huge amount of material and it's gonna focus on the fundamentals of testing. And I'm really excited to give the live workshop

as a part of Epic Web Conference. So what you're gonna learn from that workshop is basically everything you need to know to approach testing. So we're gonna start from the mental models you need to have, answering questions like what is an automated test? Why do you write it? What should you test?

And going through a lot of practical things as well, like how do you write assertions? What they are? What usefulness you get from them? And a lot of other things. There's five modules and a bunch of exercises in each module. And I try to do something interesting with this workshop.

I try to show an evolution of a single module. So we're gonna start by testing a single function and over the whole workshop, this function will evolve, change. Its intention is gonna change. So we're gonna see how we adjust or don't adjust the tests. And I just wanted to bring it closer to how people test actual code.

I really hope that folks would love the approach and testing that I'm gonna share with them. I've been using a lot of this knowledge for years and now I got the chance to finally put it in a more structured, apprehensible form. So yeah, it's gonna be awesome.

And I really look forward to seeing a bunch of people there. Awesome. Yeah, I am super excited to see that myself. And at the time of this recording, you're actually also giving a remote version of that workshop at the end of February. So if anybody is watching this at that time,

go see if there are still seats available. I'm looking forward to being there for that as well. Artem, this has been a pleasure to chat with you. I appreciate you giving some of your time today and I hope to see everybody in Park City on April 11th so we can meet you. Oh, oh my goodness. I almost forgot. There's one more question I wanted to ask you.

So when we're at the conference, there are plenty of times for breaks and the breaks are extended breaks so you have plenty of time to chat with people and stuff. So what are the sorts of things that you're hoping people come and talk with you about? You can talk about anything with me, hopefully engineering. You can also talk medicine,

but I am very bad in English terms. Oh. Yeah, let's talk about testing. Let's talk about different tooling. You can share things you struggle to test. I would love to hear those. I can share a few struggles of my own if you're interested. But yeah, just anything. You can tell me about how you got into engineering and what inspires you

and maybe discuss the last talk with me. So yeah, just don't be shy. Very good. Awesome. Hey, thank you so much, Artem. We'll see you in April. Yeah, see you all soon. Thank you.