Skip to main content

Introduction to Unit Testing

Dylan C. Israel's 86-minute Pro course teaches your first JavaScript unit tests in Jasmine, testing a single User class one method at a time across 23 scrims. Eight of the 21 teaching scrims are challenges you write yourself. Worth it if you've never written a test; skip it if you already write tests in Jest or Vitest.

Reviewed inside the course with a Pro account, September 2026.

Quick answer​

It fits developers who write JavaScript but have never tested it, especially self-taught developers heading into their first team job. The catch: you test a toy User class, not a React component or an API, so there's no in-browser final project. Pair it with Introduction to Clean Code, the natural next course from the same instructor.

Is it worth your time?​

Yes, if the phrase "I clicked through it and it works" describes how you currently verify code. Dylan opens the course with exactly that story. A lead asked how he was going to test his code. His answer was "I'm gonna click through and you're gonna see it works just like I know it does." The course is the alternative to that answer.

What makes it work is the rhythm. Almost every concept is followed by a challenge scrim that starts with a written brief in a comment block, pauses, and then walks through the solution. By the end you have written a nested describe, a beforeEach that resets a model, a spy on window.confirm that returns true and then false, and a mock service with an async method. That is a real, if small, test suite.

The scope is limited. The code under test is a User class with three name fields; there is no DOM, no React component, no fetch to a real API, and no Jest or Vitest. The final challenge sends you out of Scrimba to add tests to one of your own projects or to Dylan's 100 algorithms repository on GitHub, with no in-browser solo project. If you want a testing course that ends in something you can show, this is not it. If you want to understand what a unit test is and be able to write one tomorrow, 86 minutes is a fair price.

What you'll learn​

Scrimba lists this course as a flat run of 23 scrims with no modules. The groupings below are mine, based on what each scrim covers, so the page has something to navigate by.

Course curriculum

8 modules · 23 lessons

  1. Introduction and Jasmine setup19 min5 lessons
  2. Grouping with describe and your first test11 min4 lessons
  3. Setting up data with beforeEach11 min2 lessons
  4. Skipping and focusing tests6 min2 lessons
  5. Spies10 min2 lessons
  6. Mocks14 min2 lessons
  7. Additional matchers, final challenge and outro13 min4 lessons
  8. Scrimba wrap-up scrims3 min2 lessons

I counted 23 scrims and about 87.5 minutes by adding per-scrim durations (84.5 minutes for the 21 teaching scrims). Scrimba's header says 86 minutes and its structured data says 1h 26m 49s and 24 lessons. Neither figure matches the rendered table of contents exactly, and one lesson id (~02) is missing from the sequence.

Inside the course, module by module​

1. Introduction and Jasmine setup (19 min, 5 scrims)​

Title card of Scrimba's Introduction to Unit Testing course: the name and teacher Dylan C. Israel on lavender and mint.
Five scrims make the case for testing, define a unit test, and wire up Jasmine from script tags with no npm install.Title card from scrimba.com.

The six-minute Introduction is a slide talk. Dylan introduces himself as a self-taught frontend engineer at Amazon, then makes the case for testing. "It increases our code confidence, and this is everything." He names the three A's (arrange, act, assert) and mentions test-driven development only to say the course will not cover it. He also explains the choice of Jasmine. Jest, he says, "has been slowly taking a little bit of the market share... and Jest is based off Jasmine."

Introduction to Jasmine is a short second slide talk. Its useful idea is the definition of a unit test. "We don't actually care if you click a button, it fires off something. We care that that method that gets called when that button is clicked does what we think it does."

Setting Up Jasmine from Scratch is the first code scrim. Dylan renames index.js to main.js, then pastes in four boilerplate files: jasmine.js, jasmine.css, jasmine-html.js and boot.js. He calls jasmine.js "a six thousand line piece of library". He wires them into index.html with script tags. There is no npm and no install; the test runner is an HTML page. He warns that testing a React or TypeScript app needs more configuration and leaves a link to Jasmine's React tutorial.

Understanding the 3 parts of testing shows the whole shape in under two minutes: a describe, an it, and an expect(false).toBe(true) that fails. Dylan sums it up in that lesson. "The typical flow of your test from start to finish is you have a group, you have a test, and you have an expectation for what that test means to pass." Testing Setup Breakdown then tours the files. It also shows that a function without a return fails a test because it returns undefined.

2. Grouping with describe and your first test (11 min, 4 scrims)​

The code under test arrives: a User class with firstName, lastName and middleName, each defaulting to an empty string. Grouping with describe adds a describe('User') block and makes the point Dylan repeats throughout the course. "Don't remember what the describe method does. Remember that you're gonna need a way to group your test."

The first challenge asks whether there is a more reliable way to name the group. The answer is describe(`${User.name} Class`), so renaming the class to Admin updates the label. Our first test writes the actual test: arrange { firstName: null }, act by constructing new User(data), assert expect(model.firstName).toBe(''). Dylan then breaks the class on purpose and watches the test go red. "This is the power of unit testing."

Introduction to Unit Testing, first test lesson: a code editor beside a test reporter turning red on a failed check.
At 3:26 of Our first test, Dylan deletes the || '' default from firstName, and the result reads Expected null to be ''.Screenshot of scrimba.com, taken by scrimbaguide.tech.

The challenge that follows asks you to write the same test for lastName and middleName and group all three. The lesson I took from it was the warning about copy-paste. "I can't tell you how many times I've done something like this and accidentally had two tests testing the same one item."

3. Setting up data with beforeEach (11 min, 2 scrims)​

beforeEach is introduced as "a test setup method. It does something before each test runs." Dylan moves model = new User() into it and deletes the arrange steps from all three tests. He proves the ordering with console.log calls.

The challenge is the longest so far at nearly seven minutes. User gains a fullName getter that returns "Dylan C. Israel" when there is a middle name and "Dylan Israel" when there is not. You write a new describe('full name'), a nested beforeEach that builds a user with a first and last name, and two tests. Dylan writes the test names before the code and says why. "Oftentimes, when I am writing my code, I'll write the test cases before I actually write the code." He also insists on an explicit arrange step even when it is redundant. "You want to be expressive in your test."

4. Skipping and focusing tests (6 min, 2 scrims)​

fit and fdescribe run only the focused test or group; xit and xdescribe skip one. Dylan's framing is practical. "It's going to get a little overwhelming when you have five thousand tests and a hundred of them are broken."

The "challenge" here is unlike anything else on Scrimba. The brief in the comment block asks you to listen, raise your right hand and say "I will be a quality developer that protects the code and my sanity". Then you type a sentence promising to educate others about testing. It is a four-minute slide talk about why skipping and focusing are "a development only item" and should never ship. Dylan says it was "clean code principles, solid principles, and testing" that doubled his income early on. He calls it a soapbox himself. I found it more persuasive than I expected.

5. Spies (10 min, 2 scrims)​

User gains a sayMyName() method that calls window.alert(this.fullName). Dylan picked it for a Scrimba-specific reason. "Scrimba actually can't call the alert method because of the way the platform is built and nothing's going to pop up, but we can write our test to actually see that it does get called using a spy." The test is spyOn(window, 'alert'), then model.sayMyName(), then expect(window.alert).toHaveBeenCalledWith('Dylan Israel'). He explains what spies are for. "You're not gonna test the library. Typically, what you're gonna test is that your code calls the library and passes the correct data."

The Spy Challenge is the hardest one in the course. It includes a hint for something not yet taught: spyOn(object, 'key').and.returnValue(value). getCodeName() calls window.confirm("Are you a testing god?") and returns one of two strings. You have to write three tests: the confirmed case, the declined case, and a check on what confirm was called with. Dylan anticipates the mood. "You may be getting frustrated at this point saying, Dylan, why don't you just set this up for me instead of doing this in challenges? ... embrace the frustration." At the end he points out that his own test description said "coding god" when the code said "testing god". He turns it into the lesson that "your tests are only as good as your test descriptions."

Introduction to Unit Testing, spy challenge lesson: a code editor shows an empty test block and a no specs found reporter.
The Spy Challenge brief as the scrim opens: three numbered lines and an empty describe block, with a hint for a method the course has not taught yet.Screenshot of scrimba.com, taken by scrimbaguide.tech.

6. Mocks (14 min, 2 scrims)​

Mocks + Debug with me! is the longest scrim at 9 minutes 19 seconds. A user-service.js file with a real API path appears. User now takes the service as a second constructor argument, and an async getMyFullUserData() calls it. Why mock at all? Because your tests run "hundreds, if not thousands, of times a day, every time you save your code... that gets very expensive very quickly."

Dylan builds a mock user service by hand: a lastId property, a userData object, and an async getUserById(id) that records the id and returns the data. The test awaits the call and expects lastId to be 1. It fails. The next three minutes are unscripted debugging until he finds the assignment was not in the right this context. He leaves it in on purpose. "I like to leave my mistakes in there so you can kinda see a debugging process... instead of just seeing the happy path." This is the scrim I would point a skeptic to.

The Mocks Challenge asks you to remove the unused parts of that test and write a second one checking the returned user data. It also sets up the next lesson by showing that expect(result).toBe({...}) fails even when every value matches.

7. Additional matchers, final challenge and outro (13 min, 4 scrims)​

toBeDefined() is presented as the first test a test-driven developer writes ("it exists"). toEqual() is the payoff from the mocks challenge. toBe on two arrays with the same contents fails because "this array here is never going to be equal to this array". toEqual does a deep comparison instead. The matchers challenge sends you to the Jasmine docs to find one the course has not covered, because "else, you'll never escape tutorial hell." Dylan demonstrates toMatch, then explains why the course stops at five or six matchers. They cover "the ninety percent of the scenarios."

The Final Challenge is two minutes long and has no code to write in Scrimba. The brief: add tests to one of your existing projects, or clone his 100 algorithms repository and write tests for the methods there. "There's not always gonna be a tutorial for you to go and follow, and you gotta dive deep and do it on your own."

The Outro is a slide talk on being a testing advocate, the testing pyramid, and code coverage. The number to watch, he says, is branches: "did we test all the logic paths of our code?" His personal target is 90 percent or higher.

8. Scrimba wrap-up scrims (3 min, 2 scrims)​

Two Scrimba-added scrims found at the end of many courses: a two-minute Scrimbassador referral pitch voiced by Per Borgen and a 53-second certificate scrim. Neither is part of Dylan's course.

What a lesson feels like​

A typical scrim is two to six minutes. Dylan talks over a split view: main.js on the left with the class or test file, and the Jasmine HTML reporter on the right. The reporter shows "1 spec, 1 failure" or "5 specs, 0 failures" every time he saves. Because Jasmine runs in the page, feedback is immediate. You can see a test go red and green as he edits.

Challenges are announced in the file itself. The scrim opens with a comment block ("1. Use a spy and test the method getCodeName() fully"), Dylan reads it aloud, says "pause it", and the rest of the recording is the solution. There is no automatic checking and none of the "Challenge with Instant Feedback" icons that newer Scrimba courses have; you compare your code against his.

Every scrim has captions, a timestamped transcript in the settings menu, and subtitles in ten languages. The delivery is casual and rambles in places (he loses his train of thought mid-debug in the mocks lesson and says so). I count that as a feature: it feels like one working engineer showing another how he does it.

Free or Pro: exactly what is gated​

This is a Pro course. Three scrims carry a SAMPLE badge and can be watched without a subscription: Introduction, Introduction to Jasmine and Setting Up Jasmine from Scratch. That is the pitch and the setup, so you can preview about 15 minutes before deciding. Everything from Understanding the 3 parts of testing onward, including all eight challenges, is Pro, and so is the certificate.

There are no Solo Projects in this course, so the "Pro" gate is the course itself rather than a project at the end. Pro also covers the career paths, other Pro courses, and the Pro-only channels on Scrimba's Discord (the pricing page lists basic Discord access as a free feature). See current plans (opens in a new tab) for what Pro costs in your region.

How long it takes​

The 86 minutes is video runtime. With eight challenges that each need a pause and some typing, budget two to three times that: three to four hours, or two evenings. The spy and mock challenges are the ones that will slow you down, because each needs a beforeEach, an async test, and a matcher you have just met. If you take the final challenge seriously and add tests to a real project of your own, that is an open-ended afternoon on top.

Who it's for, and who should skip it​

It fits developers who can already write a JavaScript class and an arrow function but have never written a test, especially self-taught developers who want the professional habit before their first team job. It pairs naturally with Introduction to Clean Code by the same instructor; he mentions clean code principles repeatedly here.

Skip it if you already write tests with Jest, Vitest or Mocha. The concepts will be familiar and the tooling is older than what you use. Also skip it if you specifically want to test React components or an Express API; the course says up front that it only unit tests a class and leaves framework configuration to a link.

Preview Introduction to Unit Testing on Scrimba (opens in a new tab)

Prerequisites​

Comfortable JavaScript: classes and constructors, getters, arrow functions, template strings, and async/await, all of which appear in the code under test without explanation. Nothing to install; Jasmine runs from script tags in the Scrimba editor. No prior testing experience is assumed.

Where it fits​

This is a standalone skills course rather than a step in a path. The natural sequence is Learn JavaScript or Advanced JavaScript first, then this course alongside Introduction to Clean Code. The spies and mocks lessons are also good preparation for the kind of "how would you test this?" question covered in Frontend Interview Tips.

Strengths and limits​

What it does well:

  • It teaches the concepts (grouping, test cases, arrange-act-assert, setup, spies, mocks) instead of a framework's API.
  • The challenge after almost every concept keeps you typing.
  • The mocks lesson shows a real debugging session instead of a clean take.
  • The three free sample scrims let you try before you pay.

Where it is limited:

  • The code under test is a toy User class.
  • The Jasmine-in-an-HTML-page setup is not how most teams run tests in 2026. Dylan names Jest as the popular option in the first lesson.
  • There is no in-browser final project.
  • The two slide-only "challenges" (the pledge and the final challenge) may feel thin if you expected to write code.

Related Guides

Next step

Frontend Developer Path

Docs
Last updated on