[Go Make Things] An overview of JavaScript testing

By rahmat hidayat

Wednesday, December 11, 2024

​ Testing your code is one of those things that a lot of folks agree is a good idea, but that as an industry we generally don't do enough. And I personally think a lot of that is because JavaScript testing often feels complicated, time-consuming, and over-engineered. Personally, I think a lot of that comes from testing evangelists themselves, who often obsess over the the different types of tests and perpetuate complicated Rube Goldberg machines of automated testing. Today, I wanted to share some thoughts on "good enough" testing the Lean Web way. Let's dig in! The types of tests are… meh I've wasted a lot of bandwidth trying to wrap my head around the difference between unit, integration, and end-to-end tests. And I'm not the only one. Chris Coyier had a great post back in 2022 about this very topic. He wrestled with the same thing I did: integration tests are weird and it's kind of a term without value. A few years back, testing specialist Justin Searls said something that really resonates with me… People love debating what percentage of which type of tests to write, but it's a distraction. Nearly zero teams write expressive tests that establish clear boundaries, run quickly & reliably, and only fail for useful reasons. Focus on that instead. As I shared the other day, my friend Alex Riviere wrote a good post on how it's probably smarter to focus on what you're trying to test. That will determine the tool you use. What you call the test is mostly irrelevant. I'm starting to think about code you'd test as two types (versus Alex's three)… Developer-facing code. These are libraries, components, methods, and API endpoints that a developer uses to build things that end-users use. Those developers could be internal folks at your company, or external developers consuming a paid or open course product. User Interfaces. This is the stuff you build with developer-facing code In my mind, these are the two big things you test, and you have a few different tools you'll use in combination to test them. The tools I'm now thinking about my tools in three buckets… Unit tests or behavior tests. These look at small chunks of code, and verify that they do what they're supposed to do. They can be used to test individual functions in a library or component, or smaller parts of a bigger application. UI tests or end-to-end (e2e) tests. These test the output of your code in the actual UI (and can be automated now), and verify that it works as expected. Linting (sometimes called static tests). These identify typos, syntax errors, and anti-patterns in your code, and call attention to them (often in real-time as you type). What's the right mix? There isn't one, really. It depends on what your code is doing. Generally, I'm starting to think about testing like this… My linter runs all the time, and catches typos and small bugs in real time as I'm coding. Most of my testing is small behavior/unit tests I run against developer-facing code. I'll run a test for the code I'm actively building in real-time, and the full suite on the entire code base prior to deploy to make sure there are no regressions. UI/e2e tests ensure the app itself does what its supposed to and the developer-facing code was implemented properly as part of the whole app or website. These are a lot more fragile, and should be used a lot more sparingly. You might run these as part of your CI process or before deploying, again to ensure there's no regression. Standard caveats here: I'm just a guy on the internet. I don't do nearly enough testing. I'm trying to fix that. This is how I'm thinking about testing. Your wants, needs, and experiences may differ, and that's fine too! Tomorrow, we'll take a look at behavior or unit testing in a bit more detail. Cheers, Chris ​ Want to share this with others or read it later? View it in a browser.​ ​

Did someone forward this to you? Get Daily Developer Tips.

Don't want to get these emails? Totally cool. Update your subscriber preferences.

You can also unsubscribe from all emails from me, including updates to products you've purchased.

113 Cherry St #92768, Seattle, WA 98104-2205

Share :

Facebook Twitter Google+