Solving a write-tests challenge

Some DojoCode challenges ask you to write tests instead of code. The implementation is already there and it is correct. Your job is to write a test suite good enough to notice when that implementation breaks. 🕵️

You can recognize a write-tests challenge by the blue hint above the description:

How to solve: the reference solution is correct, read it. Write tests that check what it does, including edge cases and errors. Run Tests checks them on the correct solution; Verify tests also runs them on hidden copies that each contain one bug. Submit once your tests catch every hidden bug.

How it works

Behind the scenes the challenge author prepared a few hidden bugs: copies of the reference solution, each with a single small bug, such as a wrong boundary, a missing validation or a wrong value. When you verify or submit your tests, DojoCode checks them in two steps:

1. On the correct solution. All your tests must pass. A test that fails on correct code is a wrong test.
2. On every hidden bug. For each buggy copy, at least one of your tests must fail. When that happens, the bug is caught.

You complete the challenge when your tests pass on the correct solution and catch every hidden bug.

You do not know the hidden bugs in advance, and that is the point: you have to think about how the code could break. Read the reference solution and test everything it promises, including its edge cases and its errors.

The action bar has a button for each stage of your work:

Button	What it runs
Run Tests	Your tests on the correct solution only, with the result of each test.
Verify tests	Your tests on the hidden bugs, with the result for each bug, without submitting.
Submit	Both steps above, and the result counts for your score.

The workspace

Fig. 1 - The Add Numbers: Write the Tests challenge: add.js is locked, the starter test is open, and the hint above the description explains how to solve it

• The reference solution is visible and marked with a lock 🔒. Read it carefully: it is the behavior your tests must describe. You cannot edit it, and a file you create at the same path is ignored when your tests run.
• The starter test is the file you work in. It already contains one passing test to show the structure and the imports. Add your own tests next to it, or create new test files.
• The main file (marked with ▶) is the Run entry point, when the template has one. Use Run to call the reference solution and print values while you explore it.

Running your tests

Click Run Tests to run your tests on the correct solution only. The results panel shows the same results as a classic challenge: a summary of passed and failed tests, the result of each test, the console output and any errors. The hidden bugs are not checked, so use Run Tests as often as you like while you write and debug your tests.

Fig. 2 - Run Tests runs the starter test and a new test for negative numbers on the correct solution only: both pass, and the console.log output appears under Log.

Every test must pass here. A test that fails on the correct solution expects the wrong behavior: fix the expectation so it matches what the reference solution really does. Click What did I do wrong? to get an explanation from the AI assistant.

Verifying your tests

Click Verify tests to check your tests against the hidden bugs without submitting. The results panel shows:

• A summary with your passed and failed tests, the hidden bugs caught (for example Bugs caught: 1/3) and the duration.
• A verdict in one line, followed by a short reminder of how the check works.
• Hidden bugs caught: one line for each hidden bug.

Your tests still run on the correct solution first, like Submit does, but a passing run is not listed again: you already saw it with Run Tests. The results panel shows one of three outcomes.

Your tests fail on the correct solution

Fig. 3 - The test expects 6 for add(2, 3), so it fails on the correct implementation. The failing test is listed, and the hidden bugs are skipped until every test passes.

The verdict reads Your tests fail on the correct solution. This is the one case where Verify tests lists your tests: the failing tests are yours, run against correct code, so the test is wrong, not the implementation. Hidden bugs shows Skipped until all your tests pass on the correct solution: the hidden bugs are only checked once every test passes.

Fix the failing tests first: your expectations must match what the reference solution really does. Use Run Tests while you fix them, then verify again.

Your tests miss some hidden bugs

Fig. 4 - Only the starter test is written: it passes on the correct solution and catches one bug, while two hidden bugs survive, each with a hint of the behavior to test.

The verdict reads Your tests missed 2 of 3 hidden bugs. In the list of hidden bugs:

• A caught bug (green check) shows its name, a description of the bug and Caught by, the names of your tests that failed on it. This tells you what each of your tests protects.
• A missed bug (red cross) stays hidden: it shows only as Hidden bug #N, with the reminder that all your tests still pass on that buggy copy, and a Hint that names the behavior to test, for example Negative numbers, without telling you what the bug is. Its name and description are revealed once your tests catch it.

Add a test that pins down exactly the behavior from the hint, then verify again.

In the example above, the only test is expect(add(2, 3)).toBe(5). It catches the bug that adds one to every result. The other two survive: with two positive numbers, a bug in the handling of negative numbers changes nothing, and no test passes a string. Adding expect(add(-2, -3)).toBe(-5) and expect(() => add('1', 2)).toThrow(TypeError) catches both.

Every hidden bug is caught

When your tests pass on the correct solution and every hidden bug shows a green check, the verdict reads All N hidden bugs caught. Great tests!, where N is the number of hidden bugs. You are ready to submit.

Submitting

Click Submit to send your tests for the final check. The submission runs your tests on the correct solution and on every hidden bug, shows both lists, and the result counts like any other challenge: XP, streaks, contest progress and badges all apply.

Each hidden bug counts as one extra hidden test in your score. A missed bug counts as a failed test, so a green run on the correct solution alone is never 100%.

Tips for catching every bug

• Test the boundaries. Most planted bugs live at the edges: empty input, zero, the first and last element, the exact limit of a range.
• Test the errors. If the reference solution throws, rejects a request or disables a button, assert on it. A missing validation is a classic hidden bug.
• Assert exact values. toEqual('Hello World!') catches far more than toBeTruthy() or a type check.
• Choose telling inputs. Pick inputs where a bug would show. add(2, 3) cannot reveal a bug with negative numbers, add(-2, -3) can.
• Learn from what you caught. Caught by shows which test caught which bug. A test that catches nothing may be checking too little.
• Follow the hints. A hint names a behavior, not a value: test it with several inputs, including its edge cases.
• Test first, verify after. Use Run Tests for quick feedback on each test while you write, and Verify tests once your tests pass, to see which hidden bugs they catch.

Related pages

• 🥋 Solving a challenge
• 🧪 Write-tests challenges: how authors build these challenges
• 📚 Write-tests examples by template