Unit testing logic in Svelte - Step-by-Step Execution

Concept Flow - Unit testing logic

Write test case

↓

Run test runner

↓

Test calls component logic

↓

Logic returns result

↓

Test compares result to expected

↓

Report

↓

Fix code if needed

↩Back to Run test runner

Unit testing logic means writing small tests that check if parts of your Svelte component work right, running them, and fixing problems if tests fail.

Execution Sample

Svelte

import { render } from '@testing-library/svelte';
import Counter from './Counter.svelte';

test('initial count is 0', () => {
  const { getByText } = render(Counter);
  getByText('Count: 0');
});

This test checks if the Counter component starts with count 0 displayed.

Execution Table

Step	Action	Evaluation	Result
1	Import render and component	Imports succeed	Ready to test
2	Run test 'initial count is 0'	Render Counter component	Component rendered with count 0
3	Check if text 'Count: 0' exists	Text found in DOM	Test passes
4	Test runner reports result	Pass	Test suite green
5	No errors found	No fixes needed	End

💡 Test completes because expected text 'Count: 0' is found in rendered output

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
component DOM	empty	<div>Count: 0</div>	<div>Count: 0</div>	<div>Count: 0</div>
test status	not run	running	pass	pass

Key Moments - 2 Insights

Why does the test fail if the text 'Count: 0' is not found?

Because the test expects that exact text in the rendered component. If missing, the test runner marks it as failed (see execution_table step 3).

What happens if the component logic changes count initial value?

The test will fail at step 3 since 'Count: 0' won't be found, signaling you to update the test or fix the component.

Visual Quiz - 3 Questions

Look at the execution table, what is the test status after step 3?

A fail

B pass

C running

D not run

💡 Hint

Check the 'test status' variable in variable_tracker after step 3

At which step does the test runner check the component output?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at execution_table where it says 'Check if text "Count: 0" exists'

If the component showed 'Count: 1' initially, what would happen to the test?

A Test passes as normal

B Test fails at step 2

C Test fails at step 3

D Test runner crashes

💡 Hint

Refer to key_moments about what happens if initial count changes

Concept Snapshot

Unit testing logic in Svelte:
- Write small tests for component behavior
- Use @testing-library/svelte to render components
- Check rendered output matches expected
- Run tests with a test runner (e.g., Vitest)
- Fix code if tests fail and re-run
- Repeat to keep code reliable

Full Transcript

Unit testing logic in Svelte means writing small tests that check if parts of your component work correctly. You write a test case that renders the component and checks if the output matches what you expect, like showing 'Count: 0'. The test runner runs this test and reports if it passes or fails. If it fails, you fix your code and run tests again. This cycle helps keep your code working well as you build your app.

Practice

1. What is the main purpose of unit testing in Svelte applications?

easy

A. To write HTML templates

B. To style components with CSS

C. To check small parts of code for errors early

D. To deploy the app to production

Solution

1. Step 1: Understand unit testing purpose

   Unit testing focuses on testing small, isolated parts of code to find bugs early.

2. Step 2: Compare options to unit testing goal

   Only To check small parts of code for errors early describes checking small code parts for errors early, which matches unit testing.

3. Final Answer:

   To check small parts of code for errors early -> Option C

4. Quick Check:

   Unit testing = check small code parts early [OK]

Hint: Unit tests check small code parts, not styling or deployment [OK]

Common Mistakes:

• Confusing unit testing with styling or deployment
• Thinking unit tests write HTML templates
• Assuming unit tests run only in production

2. Which of the following is the correct syntax to define a test case in Svelte using Vitest or Jest?

easy

A. test('test case') { /* test code */ }

B. describe 'test group' { it 'test case' { /* test code */ } }

C. it 'test case' => { /* test code */ }

D. describe('test group', () => { it('test case', () => { /* test code */ }) })

Solution

1. Step 1: Recall correct test syntax

   In Vitest/Jest, tests use describe() and it() functions with arrow functions.

2. Step 2: Check each option's syntax

   describe('test group', () => { it('test case', () => { /* test code */ }) }) uses correct parentheses and arrow functions. Others miss parentheses or use wrong syntax.

3. Final Answer:

   describe('test group', () => { it('test case', () => { /* test code */ }) }) -> Option D

4. Quick Check:

   describe and it with arrow functions = correct syntax [OK]

Hint: Use parentheses and arrow functions with describe and it [OK]

Common Mistakes:

• Omitting parentheses around function arguments
• Using wrong arrow function syntax
• Confusing test and it keywords

3. Given this test code snippet, what will be the test result?

describe('sum function', () => {
  it('adds two numbers', () => {
    const sum = (a, b) => a + b;
    expect(sum(2, 3)).toBe(5);
  });
});

medium

A. The test will pass because 2 + 3 equals 5

B. The test will fail because sum is not defined

C. The test will fail because toBe is not a function

D. The test will throw a syntax error

Solution

1. Step 1: Analyze the sum function and test

   The sum function adds two numbers correctly. The test checks if sum(2, 3) equals 5.

2. Step 2: Evaluate the expect statement

   expect(sum(2, 3)).toBe(5) compares 5 to 5, which is true, so the test passes.

3. Final Answer:

   The test will pass because 2 + 3 equals 5 -> Option A

4. Quick Check:

   sum(2,3) = 5, expect toBe(5) passes [OK]

Hint: Check function output matches expected value exactly [OK]

Common Mistakes:

• Assuming sum is undefined
• Confusing toBe with other matchers
• Thinking syntax error occurs here

4. Identify the error in this Svelte unit test code:

describe('multiply function', () => {
  it('multiplies two numbers', () => {
    const multiply = (a, b) => a * b
    expect(multiply(2, 3)).toBe(6)
  }
});

medium

A. Missing closing parenthesis for the it block

B. multiply function is not defined

C. toBe matcher is used incorrectly

D. describe block is missing a callback function

Solution

1. Step 1: Check syntax of it block

   The it block starts with a parenthesis but lacks a closing parenthesis before the closing brace.

2. Step 2: Verify other parts

   multiply is defined correctly, toBe is used properly, and describe has a callback function.

3. Final Answer:

   Missing closing parenthesis for the it block -> Option A

4. Quick Check:

   Syntax error due to missing parenthesis [OK]

Hint: Count opening and closing parentheses carefully [OK]

Common Mistakes:

• Ignoring missing parentheses errors
• Thinking multiply is undefined
• Assuming toBe usage is wrong

5. You want to write a unit test in Svelte that checks if a function returns the correct value only when the input is positive. Which test logic correctly implements this condition?

function checkPositive(n) {
  return n > 0 ? 'positive' : 'not positive';
}

hard

A. expect(checkPositive(0)).toBe('positive'); expect(checkPositive(5)).toBe('not positive');

B. expect(checkPositive(5)).toBe('positive'); expect(checkPositive(-1)).toBe('not positive');

C. expect(checkPositive(-5)).toBe('positive'); expect(checkPositive(5)).toBe('positive');

D. expect(checkPositive(5)).toBe('not positive'); expect(checkPositive(-1)).toBe('positive');

Solution

1. Step 1: Understand function behavior

   checkPositive returns 'positive' if input > 0, else 'not positive'.

2. Step 2: Match test expectations to function logic

   expect(checkPositive(5)).toBe('positive'); expect(checkPositive(-1)).toBe('not positive'); tests positive input 5 returns 'positive' and negative input -1 returns 'not positive', matching function logic.

3. Final Answer:

   expect(checkPositive(5)).toBe('positive'); expect(checkPositive(-1)).toBe('not positive'); -> Option B

4. Quick Check:

   Test matches function output for positive and negative inputs [OK]

Hint: Test both positive and negative inputs to cover conditions [OK]

Common Mistakes:

• Testing zero as positive incorrectly
• Swapping expected results for inputs
• Testing only one input case