The 2025 State of JavaScript Testing

Hello, JS Nation. I hope you're all having an amazing conference so far. It's a huge pleasure to be here again with you. And I invite you to think about something. I'd like to invite you to think about why do you test? And this can be because it gives you the confidence that you need in the code that you're writing. Can be because it lets you sleep better at night. Can be because your boss told you so. Well, you might not even be testing. Are you?

This is a reflection that I would like to keep in mind while this talk is going through because by the end, hopefully, you'll have us coping on what's been happening in these years and where are we going in our testing years. So I would like to think of if you ever had any of the issues that you're seeing on this slide happening to you. Because well, I think I've been through the most of them. And it's painful. And when I started thinking about this talk, I thought, okay, maybe let's get some data that can back up that these issues are happening to other people. And well, the best place to get that is in the state of JS survey, which is actually open right now as I'm recording this talk. So go fill it.

But yeah, this state of JS tells us that there's a lot of pain in mocking, configuration, performance, CSS, CSS, Flakiness, browser testing issues. So these are all things that we go in through this talk. But this pain actually leads us to something. It leads us to that we are not as happy as we could be when we're talking about testing. Right now we are at 2.5 out of 4, which is not amazing. I love testing. It's like, oh, yeah, I'll do it. It's testing. So I decided to pick up on this data and start doing the state of JavaScript testing for 2025.

Just introduce myself. My name is Daniel Afons. I am a senior developer advocate at PagerDuty. I'm part of the soljs.dx team. I'm an instructor at Egg.io. I'm the author of the book called State Management with React Query.

And if you'd like to connect with me, I'm pretty much anywhere online at danieljcafons. Besides all these things, I also maintain a newsletter called This Month in SOLID. If you'd like to be updated on what's happening, this month in SOLID.js. So you can scan this QR code that you're seeing here to get a bit more of this information. So how are companies testing in 2025? It was one of the questions that I asked myself. And once again, I looked into the state of JS, which told me that well, the majority of companies are using JS. Their storybook, V-Test, Playwright, Cypress. So it gives me all of this data. But it still didn't teach me something. It still didn't tell me how are actually the companies using these tools. It gives me the tools that companies are using, but not how they're being used. So I said, okay, I need more data. So what I basically, in the beginning of the year, I sent the same message to a couple of my friends, which said, hey, could you tell me how your company is testing basically. And I left it open just to see what they will tell me. And I asked this question to eight people. And here is the data that I gathered.

So for the case 1, they're doing BDD with Playwright, using JS and the React testing library for unit and integration testing, and storybook as a component catalog. Company 2 said that they're using JS and the React testing library for unit slash integration testing, and Cypress for end-to-end. Case 3, they're using Karma and Jasmine for integration slash component testing, and JS and React testing library for unit testing, Playwright for visual regression tests, Playwright for end-to-end, and storybook as a component catalog. Case 4 is using Jest and Enzyme for integration, and WebDriver I.O. and Cucumber for end-to-end. So this gives us some patterns already. We're seeing Jest and React testing library showing up for unit integration in a bit. Let's see the other four cases that we got. Because I think it becomes better here from data-wise, I would say. Case 5, Jest and React testing library for unit integration, Playwright for end-to-end, and MockServiceWorker slash custom mocking tool for mocking their API requests. And this made me very happy, because this was the first person that mentioned MSW, and I love MSW. Case 6 is using Jest and React testing library for unit integration. Case 7 surprised me, because this was the first person that mentioned TypeScript and ESLint. So this is actually the first person that mentioned static analysis as being a part of their testing suite.

And if you know the testing profile, which we'll see in a bit, you know that these are definitely part of that scope. This is also the first person that mentioned that they're using VTest and the React testing library for unit integration, aside from using Jest. And they're using Playwright for end-to-end. And the case 8, Cypress for end-to-end, Enzyme slash React testing library for unit integration. I get this might be confusing for some of you. The rule that this company is following is they have their old code base in Enzyme, and they're migrating every new test that they write, they write in React testing library. And if someone has to touch an old test, they have to refactor it. So that's how they're doing this migration. And they're also using MSW.

So when I decided to do this talk, I said, okay, let's look at all the scopes of the testing trophy, static analysis, unit integration testing, and end-to-end. And let's talk about what is the state of them for this year. So starting with static analysis. I think that's a surprise of no one. TypeScript and YesLint are leading in, and they are continuing to be the de facto. TypeScript being migrated to Go makes it even faster, more performance. So I don't see this changing. However, there are some contenders out there. And a lot of people are using Biome or OXLint to replace some of these tools. Which are strong contenders, are working pretty well. So the state of static analysis in 2025, in a very short way to keep it is TypeScript and YesLint are not going anywhere, but there are these two other tools that you can keep checking and figuring out, okay, maybe I should use them.

So now let's go to the part where I think we're going to take a bit longer. When we're talking about unit and integration testing. Because I want to go over a timeline. Ten years ago, we were all using Karma and Jasmine, and we were writing these BDD tests, and what we actually called them back then were component tests. They were running in a browser, and we had an issue. The issue was that they were slow, they were flaky, we had issues with CICD, so we needed something better. So we did our first transition. And we migrated into something that was now node-based. So JSDOM showed up, and we did Jest showed up. So what JSDOM does, it polyfills these browser APIs so that they can run in nodes.

So in reality, we don't have our tests running in a browser environment anymore. We're actually running them in a node-based environment. And that was the first migration that we did. However, then we needed something else. And this was 2018, and something happened in the JS world, which was React hooks came out, and also the testing library was created. And with the testing library came its main philosophy, which is the more your tests resemble the way your software is used, the more confidence they can give you. And this kind of originated what I like to call the back-end fallacy in categorization pain, because now we were writing our tests focused on a user-centric approach, and this started getting a lot of confusion for a lot of people.

Not everyone now knew what a unit was, what an integration was. And I've worked in different companies since 2018, and I've worked with different people since 2018, and everyone has different definitions in their organization, what a unit and what an integration is. And this is the categorization pain part. When I'm talking about the back-end fallacy, the testing library challenged this point. The back-end fallacy was when I learned testing, for me a unit was something that was focused on the implementation details of that unit. And now this was being challenged. So all of these things, all this back-end fallacy and this categorization pain kind of made it, this back-end fallacy kind of made the categorization pain worse, because now our unit was no longer something that wasn't focused on implementation details. Our unit was basically, could be just a single component, for instance.

So I think that this is something that's important to mention, because then we did the transition to using the testing library. However, then we started having another issue around 2020, 2021, where we started discussing test runners and bundler integration. So I don't know about you, but if you ever had to configure a webpack file to get your tests running and Jest running with it, you know it was a config hell. And it was not just that. Jest has been stuck in time. And when I mean that it's been stuck in time, just look at things like Tyrescript support, which is experimental in 2025. Look at things like ESM support, which is experimental in 2025. Meanwhile, you have things like Storybook 10 that's going ESM only, and they're already seeing a decrease in 15% of the package size, so it makes it imperformant. In the meantime, ESM support is still experimental in Jest. So we needed a test runner that's aware of its environment, and it works together with the bundler. In theory, what we want and need is we want to build our tests the same way that we build our application. So then we did the next transition, and we migrated to VTest, VTest working together with VTest, and we even started using this thing called ApiDom, which is basically also built on top of JestDom. It's Jest. It's just faster, basically.

It's just faster, basically. No, sorry, it's Jest, it's JestDom, but faster. It decreases the use of certain APIs so that it's faster, basically. So it's still JestDom-based. And JestDom is the next thing I would like to discuss, because now, weeding into these here, Artem, the creator of MockServiceWorker, wrote this amazing blog post. That might be too long for today's attention span, which is 10 minutes, but I made it shorter for you. So in this article, Artem goes into why you won't use the JestDom, and talks about the JestDom issue, which is okay. It runs in Node, polyfills browser APIs, and it's basically executing browser-like code without an actual browser. It runs in Node, and he has this quote that I really love there. It says, JestDom runs in Node, pretends to be a browser, but ends up being neither.

So what is Artem proposing with this? Well, he gives another quote, which says, the closer your test environment resembles the actual environment where your code runs, the more value your tests will bring you. So what am I telling you? What does this actually mean? It means, what, should we go back to the browser? Yep, that's exactly what I'm telling you. VTest introduced browser mode, and we are going back to writing component tests. And that's basically the next shift into this. And I know it says experimental, but the experimental is only in the sense that some of these APIs might change a bit, but the core features will still be the same.

And I gotta tell you, I've been running stuff in browser mode since April-March this year, and I've been quite happy. I haven't had any of the issues that we had before, because now, in VTest browser mode, these tests are no longer slow. Obviously they are two or three seconds slower than the ones only based in Node, but the confidence that you have, because now you're running them in an actual browser, I can deal with three seconds. They are not flaky. And they work with CICD, because you can just plug it in and you can use the stuff like the playwright adapter so that you can run it in your pipeline. And I know what you're thinking. So now I have to do a full on migration. Well, actually you don't have to. It's very, very simple. It's a matter of basically swapping two imports, going from the VTest to the testing library to the VTest browser react, in this case, and changing some of the utils. Also making sure that your tests are now asynchronous. I did this migration and I learned that basically there were five steps that I had to do aside from swapping these imports, which I really love. The first one, you get rid of every query by find by, because now there's only get by when we're talking about the testing library. The second part, get rid of all the testing library you wait for, because now everything is asynchronous and it has automatic retries built out of the box. That's the value of having the VTest browser mode here.

Obviously it won't retry forever. You have the timeouts, but it has automatic retries out of the box. So you don't have to leverage these asynchronous utils.

The third point was change mock service worker to worker mode because now it runs in a browser, no longer running in the node-based environment. One tweak there is to make point four turn all of the tests asynchronous, and point five get rid of all the unnecessary mocks. There is no need now to mock things like local storage or session storage because you can actually use them in the browser. You can go back to using browser features rather than having to mock stuff that JestDOM wasn't probably feeling for you. This made me very, very, very happy.

So you might be thinking, okay, that's kind of cool, but I still don't have the confidence that we should do it. If you don't trust me or Artem, you can trust him. As he said, he actually did this tweet before I started doing the first version of this talk, which made me very happy. Never been so happy to see people uninstalling testing library. It's incredibly validating that the testing library has been successful, adopted, rewritten natively by Playwright and VTest. My work here is done. And that is fantastic because if the person that told you in 2018 to start using this thing is telling you maybe you don't need this thing now. Let's go all back to the browser because the technology works back for us. This is kind of a whoop. But that's how it feels like being in the JavaScript land for the past years.

And this is kind of a whoop. But that's how it feels like, being in the JavaScript land for the past years. Remember, like in 2020, 2021, everyone remembered when we were talking about frameworks, maybe we should go back to doing server-side rendering. And that's because the technology was better. The technology allowed us to go back to doing server-side rendering. And that's the same thing it feels like with testing. The technology is better, it's working in our favor. And now we can do component testing with the security and the technology and the performance that we didn't have ten years ago. So, the future is in VTest. The future is in VTest. And obviously, the testing library principles are still there. But that's all you need now. So, I'm very excited to see where we're gonna be in two to three years. And if these migrations start happening.

So, next, let's talk about end-to-end. And I think, to the surprise of no one, Playwright has been winning the adoption. I think Playwright has been winning for the reasons of community. The Playwright community has been growing and growing and growing. And it's being nurtured. It's being cared for. And when you see the community growing and growing like that, that explains all the growth that we're seeing in Playwright. So, I still see Cypress and WebDriver winning, playing and being used. They're not going anywhere. But Playwright, as my vote to starting with, and if you're just picking something out. And if you want something that's maintained and has a lot of things out of the box that you didn't have in these other two, Playwright is your go-to. One thing I noticed, though, when we're talking about when I was doing research for this talk is that our end-to-end solutions are becoming more than just end-to-end. What I mean by this is all of them have variations of visual testing. All of them have variations of component testing. All of them have variations of API testing. And all of them have variations of accessibility testing.

And it's not just the tools that we typically associate with end-to-end. Storybook. Storybook allows you to run all of these tests as well. This tool that many of us only consider to be where we could see our design systems, it's pretty good. And it allows us to run these tests pretty good as well. So when we're talking about now and looking back on our testing trophy, I think that this is where we're going. And this is our new representation of what a testing trophy should be like. We have our static analysis still there, our unit logic there. But now we're running component tests and end-to-end around this scope. And while around all of these things we have the visual and the accessibility testing. So that is the state when we're talking about this type of analysis.

Let's talk about something next, which is mocking. I would say to the surprise of no one, hopefully, is that MSW has become the network, the community and the industry standard when we're talking about API mocking for JavaScript. It's pretty great. GraphQL, WebSocket, for browser, for Node, React Native, and the community has been growing and growing and growing. And one thing that's exciting me a lot on MSW as well is that Artem has been working on support for cross-process interception, which means that you're going to be able to mock stuff on the server and on the client, which allows you to mock things like server components, server functions, and in these use cases, which just makes it even more powerful than it already is and it saves you a bunch of time, I would say. So if you're not using MSW yet for mocking your network APIs, go do it.

So we are in 2025, obviously, and we have to talk about AI. Obviously. There is a talk in 2025. We need to have the AI bit in it. And obviously, Copilot and all of these tools that we're using are great pair programming buddies. However, we need to make sure that our sources are being checked, especially if you're adopting things that are still in experimental phases or are very recent, like component testing and the testing, like component testing and Vitest browser mode, because these are all stuff that, well, are experimental at this point. So obviously, these models might not be trained on it yet. You can give them some context, but make sure that you're checking your sources. AI should be there to complement your knowledge. It shouldn't be there to replace it. It will speed you up definitely a lot. Just make sure that you're not using it as a way to not learn how to use your tools properly. The next point is MCP, and we're seeing MCP blow up in the testing circuit a lot.

Playwright has MCP support, Midscene has MCP support, ESLint has MCP support. So, all these tools are leveraging MCP, and you can use it to do awesome things. In Playwright's case, in Midscene's case, you can use it just to basically tell your LLM, hey, go to this website, do this bunch of actions, and then use the tools that you used, leverage the tools that you used to do these things, to generate me a test. And it will give you your test, which is pretty, pretty cool. Just once again, make sure you check if it's actually the outcome or the actual test that you would write.

How far are we from self-healing tests? In 2024, there was already this company that did this amazing blog post, and they already had a version of what self-healing looked like for them. However, I feel like this, like AI, might be already a bit... Like some stuff in AI might already be a bit outdated, because, well, now we have things like AutoPlaywright, CyPrompt, and Midscene that allow you to write this test, where you just use natural language, and it will generate your test out of it. This is the closest that I think we're going to be to self-healing in tests for a while, because, well, you say fill username field, fill password field. The model doesn't need to know where these things are at that moment. So even if you refactor your page for a while, or if you tweak it, it will still find them. So these tests might recover a bit and might be the closest that you get to self-healing.

One thing that's important to note when we're talking about these things is, they tend to be slower, because you still have to go to when you're still leveraging an LLM, still leveraging a model, so it still needs to go there and back to do all the reasoning, the thinking, and figuring out where stuff are. So these tests might come at a cost. And here these examples are in Midscene, which is built by ByteDance. And speaking of ByteDance, they also created this thing called UiTars, which is an open source model agent built upon a VLM. So a VLM is a vision language model that will integrate advanced reasoning enabled by reinforcement learning. And interestingly enough, UiTars is super powerful. This thing is even better playing Doom than I am, which I'm not good at. But when you have a comparison of an LLM versus a VLM, it basically screenshots the entirety of the page and looks into it, instead of getting text looking at a representation of your HTML or screenshot of how your page looks like and reasoning. This is the difference between using an LLM and VLM for your tests. ByteDance saw some scenarios that using UiTars, the prompts don't have to be as descriptive as you are when you're using GPT. However, when you're using stuff like GPT, they are better when generating assertions. So there's these pros and cons when we're measuring each one of them, I would say. So yeah, going back to where we were in the beginning, we started looking at this graph that interestingly enough said that 13% of the people don't test. And if you're not testing, start testing, please. And it took us through this journey of me asking a bunch of friends how we're writing our stuff and starting doing an analysis of where we are and where we're going. So let's recap what is the actual state of JavaScript testing in 2025. First, everyone will keep doing their own things and having different ways to test. I don't see that changing.

Everyone likes their opinions. Everyone likes to have one. And testing can be extremely opinionated. So keep this in mind as you're starting discussions about testing. If you're actually starting discussions about testing. We're in 2025. I don't know where this is happening or if this is happening. But it might lead into one of my last bits.

TypeScript and ESLint are the best way to do static analysis and that's not changing. Vtest brought a shift in test runners we were long expecting. End-to-end testing is so back and we are going back to the browser, baby. Yeah, that sounded cringy as heck. But that's the value we're going to get out of it.

MSW is a de facto solution for network mocking. End-to-end solutions are pushing into a testing tool suite. API, accessibility, visual component, end-to-end. And I'm interested to see what's happening there. Because we saw a lot of companies doing the peak of server components. Just deciding to only write tests with Playwright.

Just deciding to only write tests with Playwright. And now with tools like Playwright giving us all of this suite. Are these companies going to even think about going into Vtest and try to go back to what we're doing before? I'm curious to see how this part is going to progress. When talking about AI, it won't fix your knowledge gap. But it will make you more productive. That's definitely something to keep in mind. And it might lead to self-healing but at the cost of speed.

And finally, still going on the first thought that I had here. We should stop considering tests second-class citizens. They should be as important for you as writing your code is. Because tests are the things that guarantee you that the business logic and the value that your code is building is actually there. So no more I don't have time for testing or no more how can I justify someone from my team that I'm going to need extra time to do this stuff or I hate testing. Tests are as important as the code that you write or even more.

So no more having them as a second-class citizen, please. So yeah, with that quote, everyone, I would like to thank you so much for watching this talk. If you want to connect with me, you can scan this QR code. Find me pretty much anywhere online at danieljosephones. And I hope you're having a great conference and continue to have the rest of a great one. So see you around, everyone. Have a great one. Bye.