The 2025 State of JavaScript Testing

Hello, JS Nation. It's a real pleasure to be here to do another talk. And let's not waste time and get right to it, shall we? I would like to open this talk with a question. I would like to invite you to reflect. Why do we test? It can be for many reasons. It can be because you like to sleep better at night. It can be because the tests give you confidence and make your software feel more resilient. It can even be because your boss told you that you have to do it. Why do you do it? This is the opening question I would like you to consider and think for a bit.

Now, I would like to shift gears. I would like you to... If this was in person, I would ask you to raise your hand. I would like you to raise your hand virtually if any of these situations have ever happened to you. If you ever had flaky tests, if you ever had complex tests, if you ever had slow tests, lack of ESM support, lack of TypeScript support, too much boilerplate, mocking being painful, testing tools being hard, or testing tools being hard to maintain. If you ever had one of these problems, then you're very likely in the majority of people. If you haven't had any of these problems, then come talk with me. I really am really interested to see what are you testing and how you're testing.

But when I decided to start doing this talk, I interviewed a couple of people, I did some research, and one great resource for helping me prepare this talk was the state of JavaScript. And in the state of JavaScript, we talked about testing. In there, one of the questions was where is our pain? And interestingly enough, the majority of people feel pain with mocking, with configuration, with performance, with Jest, with ESM, and CommonJS, which is something that we'll talk about in a bit. There's a lot of pain in testing, and this kind of leads us to our happiness levels not being quite there. This is an NPS score, we're about around 2.5 right now, we haven't ever reached a 3, so people are satisfied. It feels like what we have is enough, but it's not perfect, we're not there in the ideal world yet. So let's go for a ride, and let's figure out what happened in the last few years due to the 2025 state of JavaScript testing.

So before we continue, my name is Neofons, I'm a senior developer advocate at PagerDuty, I'm part of the SolidJS DX team, I'm an instructor at Egghead.io and I wrote a book called State Management with React Query. Besides this, I write a newsletter every month called This Month in Solid, where you can keep track of what's happening in the world of SolidJS, and I just released a free course on Egghead called Getting Started with Solid Start, if you want to check it out. You can find me online at any handle called DanielGCFons. So let's get back to the talk, shall we?

One of the things that I really, really wanted to know is how companies are testing. And the state of JS gave me some ideas, it told me okay, a lot of people are using JS, a lot of people are using Storybook, some people are using VTest already, Playwright, Cypress, Testing Library, Mocha, Puppeteer, Selenium. But this is raw data, and I actually wanted to think about and ask people, okay, how are you testing? And I would like this to come from people all over different companies, from startups to companies in the Fortune 500 to figure out how they are testing and how their tests look like. So I interviewed 8 people, and let's review what they told me, shall we?

The company one told me that they're using BDDs, Behavior Driven Development Testing, with Playwright. They're using Jest and React Testing Library for unit and integration testing, and they're using Storybook as a component catalog. The second company told me that they're using Jest and React Testing Library for unit integration, Cypress for end-to-end. The third company told me that they're using Karma and Jasmine for integration and component testing. And Jest and React Testing Library for unit. Playwright for visual regressions, Playwright for end-to-end, and Storybook as a component catalog. The fourth company told me that they're using Jest and Enzyme for integration, and WebDriverIO with Cucumber for end-to-end. So do you identify yourself with any of these companies already? Is this something that you are currently experiencing? Think about that for a bit, while we go for the other company.

So when we get to this case 5, and eventually I think it's case 7, things get a bit more interesting. Because the question that I asked the people in these interviews was a very simple one. Could you just tell me what is your testing stack look like, and what type of tests you're writing? How do you test? And I think with case 5, it's where I first heard people mention mock service worker. I've been using mock service worker for years. We'll get to it in this talk. But this is the first company that told me, yeah, we have Jest and React Testing Library for integration, Playwright for end-to-end, but now we're also using mock service worker and a custom mocking tool for mocking our network requests and others. Case 6, Jest and React Testing Library for unit integration. And the case 7 was actually the first person to ever mention static analysis. If we're talking about the testing trophy, which we'll talk about in a bit, static analysis is a great part of it. And in this case 7, they're using TypeScript and ESLint for doing some static analysis. VTest and React Testing Library for unit integration, and Playwright for end-to-end. Finally, for case 8, we have Cypress for end-to-end, Enzyme and React Testing Library for unit integration, and MSW with a custom mocking tool, and a custom mocking tool. So, this is a bit of an overview that goes for 8 different companies in 8 different contexts. And it's a very interesting thing when I was doing this talk, because now, when we have been taught the testing trophy and Kent Cedald has explained this to us, and we have learned this from the past few years, we always thought about these 4 topics, end-to-end, integration, unit, static, even though a couple of them got a bit blurry throughout the years, these have been the testing points that keep us safe. So I thought, okay, let's use these 4 points, the static analysis, the unit integration, and the end-to-end to see how are we doing tests and what's the current standard for using these things.

Let's start with static analysis. Let's start from the bottom and go up from there. Well, to no one's surprise, TypeScript and ESLint are still the standard for doing static analysis. They are more than proven, they're battle-hardened, and I don't see anyone saying that they don't want to use them. If I would have you something to keep in mind and keep under your radar is to check Biome and OXC. There's some interesting developments happening there from a static analysis perspective, and I've actually seen a couple of people migrating out of ESLint to Biome already, and some organizations, so they're here, they're giving a couple of people already some different decisions and different tests, so this is basically my analysis for the static analysis part.

Now, let's spend a bit more time talking about unit and integration testing, because this is the one that I think most of us get excited about, let's say excited. For that, I wanted to do a timeline, because, well, a couple years we were writing tests, a couple years, ten years ago or so, this is where we were. We had a bunch of tests using Karma and we were using Jasmine, and these were all component testing. These tests run in an actual browser, but we had a couple of issues with this. First of all, these tests were not always reliable, they were a bit flaky, the browsers were always crashing, and let's not talk about how the heck we could get this into a CI-CD pipeline. So we made a transition, and this transition meant, okay, now we don't want to run stuff in a browser environment, we want to simulate a browser environment in a node-based environment, so we came out with JestDOM, and on top of JestDOM, we had Jest, and we paired it with Enzyme, as a testing library, to write our tests. And this is where we were around 2017, 2018, but in 2018, I think, that's when something changed, and I would like to call it the backend fallacy and the categorization pain, because this is what happened in 2018. The famous tweet that changed the way we did testing in the frontend, in the JavaScript world. The more your tests resemble the way your software is used, the more confidence they can give you.

And this changed the way we did our tests, because now we were focused on a user-centric perspective. And the reason why I call this the backend fallacy is because, well, the majority of us, myself included, we weren't testing from a backend perspective. That's how we did testing for years. And now we were being encouraged to skip the implementation details, and only think about it from a user perspective. Now a unit would be an individual component, and an integration would be components working together. That's the definition that we were going with, and it also became a bit more confusing for a couple of people, because some people now didn't know how they should be testing, or how they should call their tests. But either way, what happened now was that we moved out of Enzyme, and we started using the testing library. And that's where we were in 2019.

Then another problem came, which was we had some issues with our test runners and bundler integration. So, I don't know if you remember these issues that we had with Jest, but, well, I'm just gonna name a couple of them. It was a huge pain to configure, just to make sure that we could get everything working. It was stuck in time. Do you want a reason for it being stuck in time? Just look at TypeScript support and ESM support with Jest, which currently, right now, it's still experimental with the ESM part. Why? Well, I have no idea. So, we needed a test runner that ideally would be aware of its environment, and would work together with its bundler. Instead of us having to configure this stuff ourselves, we wanted to build our tests the same way that we build our application. And this is where VTest showed up.

Now, we also did some changes here. We moved out of JestDOM to EpiDOM, which, in a very short way, it's a stripped-down version of JestDOM, which is made to be more performant, on the downside of losing some features that we had with JestDOM. But it's faster. Our tests were faster. But now, came another issue, which is the JestDOM issue. Artem, the creator of mock-service-worker, wrote this amazing blog post that I really recommend you to check. And I won't go over it, because I only have 20 minutes and I'm at, currently, 12. But I think one of the great things about this post, and one of my favorite quotes, is this one. JestDOM runs in Node.js, pretends to be a browser, but ends up being none. Because, in reality, what we're doing there is, for us to have a browser running in a Node environment, we are just polyfilling browser APIs. We're basically creating these APIs that Node environments don't have in a Node-based environment. So, we are trying to execute browser-like code without having any browser. That's the JestDOM issue.

That's what's been happening. This blog post that Artem has is really, really great. I really recommend you to check it out. But another quote, and I think that's the quote that's going to shape, again, how we're doing tests, in the front-end, is this one. The closer your test environment resembles the actual environment where you run code, the more value your tests will bring you. So, you might see the parallel between the testing library quote, because it's very similar. And it's actually true. Think about it. We run our code in the browser. So, why shouldn't we test our code in the browser? Heck, you might say, in the Karma days, everything was flaky, everything was crashing, but now we have a better experience. And this is why we believe that what's coming next is VTest browser mode.

So, the VTest browser mode is basically what it says. We're doing component testing. We're bringing everything back to the browser. And now you might be thinking, oh, so I have to go ahead and refactor everything again, spend months and months and months doing so. Well, you don't do. This thread that Artem did, it's basically just a matter of swapping two imports. I had a couple of other things, but at the end of the day, it took me 20 minutes to do this for a 50 test suite. Now, I know it might be tricky for you to take this and think, oh, so now you're telling me that I need to move my unit integration tests to the browser. It means that I need to get out of the react testing library or start doing something else. Well, it's not only me and Artem that are telling you. Kent is telling you the same thing.

So, what I say here is if we trusted Kent back then to help us lead the change into how we were doing testing, let's do it again. Let's move stuff back to the browser. Because at the end of the day, and one thing that I've noticed is the tests don't get that slow. It's a one-second difference. And to be honest, I can live with a one-second difference in my tests, considering that everything else will give me the confidence that I'm running them exactly how my users are running their code. So, yeah, that's where we're going. The future is in component testing regarding the unit integration part. So, now let's move another step and talk about end-to-end.

Well, to the surprise of no one, I would say, Playwright has been winning this adoption. Webdriver.io and Cypress still have a lot of companies using them. But, well, what can I say? Playwright community and the Playwright team have been doing a fantastic job. And it's not just that. It has features like Codegen and tracing, which are fantastic and save you a bunch of time. It's cross-browser, cross-platform, cross-language. If for some reason you can even write your tests in Python, let's not get there. And you can use it to test mobile web applications as well.

So, and there's a bunch of other things there like parallelism for free, which was something that was paid in another solution in the past. There's a lot of discussions there. But either way, I think regarding end-to-end testing, what I see happening is Playwright keep getting more and more interest. And becoming one of the most adopted solutions by the end of 2025. One curious fact that I noticed while I was preparing this presentation is that end-to-end solutions are becoming more than just end-to-end. And what do I mean by this? Well, it means that they can do visual testing. It means that they can also do component testing. Playwright does component testing as experimental and Webdriver.io as well.

They also allow you to do API testing. And they allow you to do accessibility testing. And it's not just end-to-end solutions. Storybook, the typically known thing as the component catalog, also allows you to do this. So, I see end-to-end solutions are trying to get into this developer space of trying to also capture a part of, okay, how do we test other stuff aside from end-to-end? Let's try to bring some of these things into our own solution. At the end of the day, it's going to depend on each company what they want to do. But I think that this might be where we're going and what's happening in the next couple of years. We have the static analysis. We have the unit tests. We now get to migrate these integrations to component tests because component tests is a form of integration either way. And we have the orient-to-end for the full flow. Between these slices, we have visual and accessibility. But this, friends, is where I believe testing is going and what's coming up next year.

But this, friends, is where I believe testing is going and what's coming up next year. Now, with the rest two minutes that I have, let's go through ten slides.

Mocking. This is a very interesting one because I think to the known surprise, mock service worker is the standard for network mocking. I don't think there's anything better. It supports REST, supports GraphQL, it supports WebSocket. It works for browser, Node, React Native. It has even a great ecosystem with stuff like MSW AutoMock, which is a CLI tool that allows you to generate mock data from an open API definition for MSW.

And one of the really interesting things that I've heard Artem mention recently in an interview that he did is they're working on cross-process interception. What does cross-process interception mean? It means that it will allow developers to control network requests across different process boundaries. So what does this mean? It means that it will allow you to mock stuff for server components. You will finally be able to figure out how to test these things in a lower level than just end-to-end. That's really, really exciting. And I can't wait to see what mock service worker keeps doing and what Artem keeps bringing for this. This is such a perfect library. I love it so much. And, yeah, let's go into the mandatory AI part.

So for AI, to no one's surprise, Copilot has been helping us speed up tests. It's really great. It saves us a bunch of time. It's a very good pair programming buddy. Just make sure that you check its sources sometimes because there have been plenty of times that it's been trying to use some outdated information. But, well, it's perfect. It's great. Other stuff that we're also seeing. So there's this thing called autoplaywrite which allows you to basically use natural language to write playwrite tests. So you just say do this, do that, do that. And there's some tools that do the same things like MeetScene, CodeSept. There's just one consideration that you should have when you're writing this type of test. It's AI-based tests are still slower.

Remember, this language still needs to be processed. It still needs to go to your model. It still needs to figure out. So there's still some slowness associated with AI-generated tests. But I feel like the AI in testing is going to keep getting better and better and better. And who knows? Eventually we might get to this self-healing reality where our tests are able to repair themselves. This is speculation, obviously. But it's exciting to see that this is on the horizon.

And I've heard people talk about that. And finally, to wrap up the AI part, playwrite just announced their MCP server. This is really, really, really cool. It allows you to connect with your model and use playwrite from there. And this allows you to automate tasks. But most importantly, allows you to generate tests automatically. You can tell your model, hey, go to this page. Figure out some test scenarios and then use the steps that you did to interact with the page to generate tests. That's pretty cool, I would say.

So I feel like this migration might change a bit. I still feel like we're going to keep getting on Jest for a long time due to the scenario of legacy code and what people have been doing and not. But I'm optimistic that we're going to see more VTests increase in the next couple of years. Playwrite is going to keep increasing. MSW is going to keep increasing. And there's some other stuff that we haven't talked in this talk. Like no test runner. But it's going to be an interesting year for testing. And I'm really excited to see what the state of Jest survey shows us next year. So to wrap up, some final considerations. Everyone will keep doing their own things and having different ways to test. I think that should be obvious. Everyone tests differently.

Everyone has their own opinion. We should be okay with that. Every company does it differently. Regarding static analysis, TypeScript and TS and the SLint are the best way to do it. Bioman and OXC are on the horizon. But so far they're not going to give them a run for their money immediately.

VTest brought the shift in test runners that we were long expecting. We now have test runners that are aware of the bundler and do the same thing together. Component testing is so back. And we're shifting this again back to the browser. Hopefully with a better experience and even working with CICD.

MSW is a de facto for network mocking. End-to-end solutions are pushing into a testing tool suite. And AI won't fix your knowledge gap. But it might make you more productive. And eventually might lead us to self-healing. But at the cost of speed. Finally, my last statement for you. We should stop considering tests second-class citizens. Tests give us the confidence they are as important as the code that we write. I've heard many arguments on why we shouldn't do tests. Or why even we should bother. Well, I like sleeping better at night. And I think that testing gives me this confidence. And it should do the same for you. So, please start giving the same importance to your tests that you give to your code. So with that everyone, thank you so much. This was the 2025 stage of JavaScript testing. I'm Daniel Alfonso, and I'll see you around. Bye.