Marks in the DOM, and time zones
Time-zone names and rules come from the browser's ICU data, so a check against Atlantic/Azores gives the same answer on every machine, unlike a check against the machine's own zone.
Most of a chart's logic is plain functions (scales, shaping, rules) that a test can check in milliseconds. Test those first, check the marks in the DOM second, pin time zones, and treat screenshots as a last, small layer.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a Vitest test for fileName(parts, ext): it must lower-case, replace odd characters with dashes and drop empty parts. Which inputs do you use?
Write a DOM test that drawBars with a negative number (rides: -5) does not put a negative height in the chart. What should the chart do?
Explain it without notes
Why test scales and data shaping before the DOM?
What would a good DOM test of a bar chart check?
How do you make a date test independent of the machine?
When is a visual regression test worth its cost?
Preview
Console
Nothing logged yet.Expected console output
PASS one bar per row
PASS the tallest bar is Tuesday
PASS heights are in proportion to rides
PASS no NaN, undefined or Infinity in any attribute
PASS an empty list gives the message and no bars
PASS one row still draws one bar
PASS all values equal give equal bars
PASS winter: 00:30 UTC on 1 Jan is still 31 Dec in the Azores
PASS summer: the Azores are on UTC+0
PASS d3.autoType reads a plain date as UTC midnight
10 passed, 0 failed