Why Writing test functions in Deno? - Purpose & Use Cases

The Big Idea

What if your code could tell you instantly when something breaks, without you lifting a finger?

The Scenario

Imagine you change a small part of your code and then manually check if everything still works by running the whole program and clicking around.

The Problem

This manual checking is slow, easy to forget, and you might miss bugs hidden deep inside your code. It's like trying to find a typo in a huge book by reading every page again.

The Solution

Writing test functions lets you automatically check if parts of your code work correctly. You run these tests anytime you change something, and they quickly tell you if something broke.

Before vs After

✗ Before

Run program -> Click features -> Hope nothing breaks

✓ After

Deno.test('check feature', () => { /* test code here */ });

What It Enables

It makes your code safer and saves time by catching mistakes early with automatic checks.

Real Life Example

Like a smoke alarm that warns you early about fire, test functions warn you early about bugs before users see them.

Key Takeaways

Manual checks are slow and unreliable.

Test functions automate checking code correctness.

They help catch bugs early and keep your code healthy.

Practice

1. What is the main purpose of using deno.test in your code?

easy

A. To write test functions that check if code works correctly

B. To run the main application server

C. To format code automatically

D. To deploy code to the cloud

Solution

1. Step 1: Understand the role of deno.test

   deno.test is used to define test functions that verify code behavior.

2. Step 2: Differentiate from other tasks

   Running servers, formatting, or deploying are not related to deno.test.

3. Final Answer:

   To write test functions that check if code works correctly -> Option A

4. Quick Check:

   Test functions = deno.test usage [OK]

Hint: Tests check code correctness using deno.test [OK]

Common Mistakes:

• Confusing test functions with running servers
• Thinking deno.test formats code
• Assuming deno.test deploys code

2. Which of the following is the correct syntax to define a test function in Deno?

easy

A. test(() => { /* test code */ });

B. test.deno(() => { /* test code */ });

C. deno.runTest(() => { /* test code */ });

D. deno.test(() => { /* test code */ });

Solution

1. Step 1: Recall correct Deno test syntax

   The correct way to define a test is deno.test(() => { ... }).

2. Step 2: Identify incorrect options

   Options B, C, and D use wrong method names or missing namespace.

3. Final Answer:

   deno.test(() => { /* test code */ }); -> Option D

4. Quick Check:

   Correct test syntax = deno.test [OK]

Hint: Use deno.test() exactly to define tests [OK]

Common Mistakes:

• Swapping method names like test.deno or deno.runTest
• Omitting 'deno.' prefix
• Using just test() without import or context

3. What will be the output when running this test code in Deno?

import { assertEquals } from "https://deno.land/std/testing/asserts.ts";
deno.test("sum test", () => {
  const result = 2 + 3;
  assertEquals(result, 5);
});

medium

A. Runtime error: deno.test is undefined

B. Test fails with assertion error

C. Test passes with no errors

D. Syntax error due to import

Solution

1. Step 1: Analyze the test logic

   The test calculates 2 + 3 and checks if it equals 5, which is true.

2. Step 2: Check for syntax or runtime issues

   The import and usage of deno.test and assertEquals are correct.

3. Final Answer:

   Test passes with no errors -> Option C

4. Quick Check:

   Correct assertion means test passes [OK]

Hint: Correct assertEquals means test passes [OK]

Common Mistakes:

• Assuming test fails when assertion is true
• Thinking import causes syntax error
• Confusing runtime errors with correct usage

4. Identify the error in this Deno test code:

import { assertEquals } from "https://deno.land/std/testing/asserts.ts";
deno.test("check value", () => {
  const value = 10;
  assertEquals(value, "10");
});

medium

A. Type mismatch causes assertion failure

B. Missing async keyword in test function

C. Incorrect import URL for assertEquals

D. deno.test requires a name and function separately

Solution

1. Step 1: Check assertion parameters

   The test compares number 10 with string "10", which are not equal.

2. Step 2: Confirm other syntax correctness

   Import URL and test function syntax are correct; async is not required here.

3. Final Answer:

   Type mismatch causes assertion failure -> Option A

4. Quick Check:

   assertEquals fails if types differ [OK]

Hint: assertEquals fails if types differ exactly [OK]

Common Mistakes:

• Thinking async is always needed
• Assuming string and number are equal
• Believing import URL is wrong

5. You want to write a test in Deno that checks if a function getUserName(id) returns a non-empty string for valid IDs. Which test function is best to write?

hard

A. deno.test("user name test", () => { const name = getUserName(1); assertEquals(typeof name, "number"); });

B. deno.test("user name test", () => { const name = getUserName(1); assert(name.length > 0); });

C. deno.test("user name test", () => { const name = getUserName(1); assertEquals(name, ""); });

D. deno.test("user name test", () => { const name = getUserName(1); assertEquals(name, null); });

Solution

1. Step 1: Understand the test goal

   The test should verify the returned name is a non-empty string.

2. Step 2: Evaluate each option

   deno.test("user name test", () => { const name = getUserName(1); assert(name.length > 0); }); checks if length > 0, which matches the goal. Options A, B, and D check for number type, empty string, or null, which are incorrect.

3. Final Answer:

   deno.test("user name test", () => { const name = getUserName(1); assert(name.length > 0); }); -> Option B

4. Quick Check:

   Check non-empty string with length > 0 [OK]

Hint: Check string length > 0 to confirm non-empty [OK]

Common Mistakes:

• Checking for empty string instead of non-empty
• Checking wrong type like number or null
• Using assertEquals with wrong expected value