Become a JavaScript Testing Pro: 14 Resources for Developers
Tags: testing, javascript, tutorial, react
Published: 2023-01-20 11:02:02

You know I have a strong passion for testing. Testing helps me to maintain good code design, stay focused on the purpose of the code, and prevent regressions in the future.

I have been (and still am) dedicating a lot of time on the quest to master the art of JavaScript testing, experimenting with various methods and technologies to achieve the best outcomes. 
Over the past year, I decided to document my journey and share it with you through my blog. It's got all the juicy details: my experiences, the obstacles I've overcome, the breakthroughs I've had, the tools I've discovered, the lessons I've learned and more.

I've been hoarding my resources on JavaScript testing like a squirrel stashing acorns. But, don't worry, I've finally put all my recent finds in one place for you, complete with a rundown of what each one covers and a link to check it out. As I was organizing them, I realized I had more than I expected (I may have a slight obsession with testing), but don't worry, I've handpicked only the cream of the crop for you to devour. 

Enjoy!

---

## 1. [Testing a simple component with React Testing Library](https://dev.to/mbarzeev/testing-a-simple-component-with-react-testing-library-5bc6)
Alright, I'll be the first to admit, testing something that's already built isn't my favorite thing in the world, but sometimes it's just what the doctor ordered. In this article, I take you on a journey of testing an existing component, step by step. We'll be using [React Testing Lib](https://testing-library.com/docs/react-testing-library/intro/) to do some fancy React unit tests, mimicking user interactions and trying out different assertion techniques. By the end, we'll even run a test coverage report to see how well we did and I'll show you how refactoring becomes a breeze when your component is fully covered.

Link: https://dev.to/mbarzeev/testing-a-simple-component-with-react-testing-library-5bc6 

---

## 2. [Creating a React component with TDD](https://dev.to/mbarzeev/creating-a-react-component-with-tdd-2jn8)
Ladies and gentlemen, step right up and witness the magic of Test-Driven Development! In this article, I'll be creating a React component using the TDD method. We're starting with a blank slate and a list of requirements, and from there, it's all about writing the test first, watching it fail, writing the code to make it pass, then doing refactoring before moving on to the next requirement. 
I know this isn't the typical way of creating components, but it's an enlightening experience. By the end of this post, you'll see that TDD can be applied, and rather easily, for UI components.

Link: https://dev.to/mbarzeev/creating-a-react-component-with-tdd-2jn8 

---

## 3. [Fixing a bug using React Testing Library](https://dev.to/mbarzeev/fixing-a-bug-using-react-testing-library-3hmh)
let's get real for a sec, we've all got bugs in our code, it's just a fact of life. In this article, I'm taking on an elusive bug, using tests to track it down, like a detective following a suspect. And once I've found the culprit, these tests act as a safety net, so I can fix it without introducing new problems. And because we're already in testing mode, why not test a redux state too? Sure, why not! 

Link: https://dev.to/mbarzeev/fixing-a-bug-using-react-testing-library-3hmh 

---

## 4. [Creating a React Custom Hook using TDD](https://dev.to/mbarzeev/creating-a-react-custom-hook-using-tdd-2o)
In this article, I'll be taking you on a journey of creating a custom hook using the TDD method. We'll begin by defining the hook's requirements, and then it's all about writing tests, watching them fail, writing code to make them pass, and a little refactoring before moving on to the next step. 
I'll also be using the [@testing-library/react-hooks library](https://github.com/testing-library/react-hooks-testing-library), which allows me to "render" a hook and perform assertions over it, it's pretty neat. So, come along and watch this hook come to life, step by step, using the red-green-refactor methodology.

Link: https://dev.to/mbarzeev/creating-a-react-custom-hook-using-tdd-2o 

---

## 5. [TDD with MSW for a Custom Fetch React Hook](https://dev.to/mbarzeev/tdd-with-msw-for-a-custom-fetch-react-hook-485c)
The inspiration for this came from a comment on my previous article (comments are like gold to me!) that challenged me to apply TDD for a server-fetching hook. Challenge accepted! 
I'll be using [MSW (Mock Service Worker)](https://mswjs.io/) to mock API calls for tests, which is pretty cool. The requirements are simple: Fetch data from a URL, indicate the fetching status, and make the data available to consume. And from there, it's a wild ride through the red-green-refactor methodology, until we reach the finish line. Buckle up and enjoy the show!

Link: https://dev.to/mbarzeev/tdd-with-msw-for-a-custom-fetch-react-hook-485c 

---

## 6. [Creating a Custom ESLint Rule with TDD](https://dev.to/mbarzeev/creating-a-custom-eslint-rule-with-tdd-120g)
We've tackled JavaScript testing and now it's time to take on the world of linting. In this article, I'll be creating a simple ESlint rule using the TDD method. 
The rule will make sure that developers can't import namespaces (“import * as ...”) from certain modules, with the option to configure it to disallow namespace imports from certain modules. 
For testing the rule, I'll be using the [RuleTester](https://eslint.org/docs/developer-guide/nodejs-api#ruletester), which is a utility for writing tests for ESLint rules, and it's quite good. The RuleTester presents a different way of batch asserting which was refreshing.

Link: https://dev.to/mbarzeev/creating-a-custom-eslint-rule-with-tdd-120g 

---

## 7. [Aggregating Unit Test Coverage for All Monorepo’s Packages](https://dev.to/mbarzeev/aggregating-unit-test-coverage-for-all-monorepos-packages-20c6)
In this post, I'll be showing you how to add an aggregated unit test code coverage report for my [Pedalboard monorepo](https://github.com/mbarzeev/pedalboard). 
Monorepos can be a bit of a handful, with many packages, and each one should have tests, and a way to generate a code coverage report. But what if you want a single place where you can see the overall coverage status of the entire monorepo? 
Well, this article will show you how to do just that :).

Link: https://dev.to/mbarzeev/aggregating-unit-test-coverage-for-all-monorepos-packages-20c6 

---

## 8. [Why practicing DRY in tests is bad for you](https://dev.to/mbarzeev/why-practicing-dry-in-tests-is-bad-for-you-j7f)
This post is a bit different from the recent ones I’ve published. I’m sharing my point of view on practicing DRY in unit tests and why I think it's a bad idea. Do you agree? 

Link: https://dev.to/mbarzeev/why-practicing-dry-in-tests-is-bad-for-you-j7f  

---

## 9. [From Jest to Vitest - Migration and Benchmark](https://dev.to/mbarzeev/from-jest-to-vitest-migration-and-benchmark-23pl)
In this article, I'm taking on a new challenger, a test framework called [Vitest](https://github.com/vitest-dev/vitest) that caught my attention. I'll be migrating my project's test runner framework from Jest to Vitest and seeing if it lives up to its claim of being a "blazing fast unit test framework". 
The migration was not without its hiccups, but I finally got it running. I hope that my struggles and solutions will save you a few minutes, or hours. Is it faster? you'll have to see for yourself ;)

Link: https://dev.to/mbarzeev/from-jest-to-vitest-migration-and-benchmark-23pl 

---

## 10. [Why Testing After Is a Bad Practice](https://dev.to/mbarzeev/why-testing-after-is-a-bad-practice-2pj5)
I'm gonna come clean, I test-after too, I confess :) but I really try to avoid it when possible. 
In this article, I'm giving my two cents on why writing tests after you have a so-called "working" code is a bad practice. It's like eating dessert before dinner, it's tempting but it's not the right way to do it. 

Link: https://dev.to/mbarzeev/why-testing-after-is-a-bad-practice-2pj5 

---

## 11. [Jest Mocking Cheatsheet](https://dev.to/mbarzeev/jest-mocking-cheatsheet-fca)
I know I'm not alone when it comes to Jest mocking - every time it's like trying to remember a phone number you only call once a year, it's just not sticking. But I got tired of searching for the same code snippets every time, so I decided to take matters into my own hands and create a Cheatsheet of the elusive mock code snippets I know. I hope it will save you some time too, and you can use it to mock like a pro!

Link: https://dev.to/mbarzeev/jest-mocking-cheatsheet-fca 

---

## 12. [Testing a SolidJS Component Using Vitest](https://dev.to/mbarzeev/testing-a-solidjs-component-using-vitest-2h35)
In this article, I'll be introducing Vitest to a SolidJS project and testing a single component. I know, I know, there's a project template for it, but where's the fun in that? I want to understand what it takes to include Vitest unit testing in your existing SolidJS project, so I'm starting from scratch and adding the required dependencies and configuration. But be warned, this is not a journey for the faint of heart... ;) 

Also make sure you check the update for this one: https://dev.to/mbarzeev/update-testing-a-solidjs-component-using-vitest-1pj9 

Link: https://dev.to/mbarzeev/testing-a-solidjs-component-using-vitest-2h35 

---

## 13. [What are you trying to test?](https://dev.to/mbarzeev/what-are-you-trying-to-test-2161)
The importance of testing is well-documented and there are many resources out there describing the benefits of maintaining a good and balanced test coverage for your code base. 
But sometimes, the need (or requirement) to write tests can cloud your judgment on what exactly should be tested. Let's talk about how to make sure we're testing the right things and not just checking off a box. 

Link: https://dev.to/mbarzeev/what-are-you-trying-to-test-2161 

---

## 14. [Testing Your Stylelint Plugin](https://dev.to/mbarzeev/testing-your-stylelint-plugin-5ceh)
I've created a Stylelint plugin that has a single rule for validating that certain CSS properties can only be found in certain files, but it was missing something - tests. 
I know, I know, it's like building a house without a foundation. You're probably wondering how this could happen, well, the simple answer is that I thought that testing a Stylelint plugin deserved its own article, so here it is! 

Link: https://dev.to/mbarzeev/testing-your-stylelint-plugin-5ceh 

---

Well folks, there you have it!
14 articles about JavaScript testing that will hopefully help you become a testing pro. If you have any questions or want to share your own testing experiences, drop them in the comments below. Who knows, maybe your question will be the spark for my next article! 

Happy testing!

*Hey! for more content like the one you've just read check out <a href="https://twitter.com/mattibarzeev?ref_src=twsrc%5Etfw" class="twitter-follow-button" data-show-count="false">@mattibarzeev</a><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> on Twitter* :beers:

<small><small><small>Photo by <a href="https://unsplash.com/@djmalecki?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Dawid Małecki</a> on <a href="https://unsplash.com/photos/fw7lR3ibfpU?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></small></small></small>