🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧪 धडा 10 — UI testing: फलक अजून उभा आहे का?

📍 तुम्ही इथे आहात: 12 पैकी धडा 10 · मागील: lesson-09-performance · पुढील: lesson-11-talking-to-backends

📦 या ब्रँचमध्ये काय आहे

धडे 01–09, आणि त्यासोबत फलक न मोडता तो कसा बदलायचा: UI साठी test pyramid (unit, component, end-to-end, visual), काय assert करायचे (class names नाही, तर roles आणि labels), आणि आधीच या repo वर पहारा देणारा कोणत्याही dependency शिवायचा smoke test. खऱ्या files:

ui/smoke_test.py — दहा तपासण्या, कोणतीही dependency नाही
ui/tests/board.spec.js — Playwright मध्ये तोच हेतू

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

कोणीही फलक पुन्हा रंगवण्याआधी, तो अजून चालतो का हे कोणीतरी तपासायला हवे. तपासण्यांचे चार प्रकार आहेत, आणि प्रत्येकाचे प्रमाण वेगवेगळे हवे:

Unit 🔬 — एक pure function वेगळे test करा. Test data सह StudentCard(s): ते नाव घालते का? जलद, भरपूर.
Component 🧩 — बनावट data सह एक तुकडा render करा आणि DOM वर assert करा ("Enrol नावाचे button आहे"). तरीही जलद; खरी जोडणी पकडते.
End-to-end 🧭 — एक खरा browser फलक उघडतो, form भरतो, Enrol वर click करतो, आणि card दिसते का ते तपासतो. मंद, कधीकधी flaky, अमूल्य. मोजकेच सोनेरी मार्ग ठेवा.
Visual 📸 — फलकाचा screenshot घ्या आणि कालच्याशी diff करा, म्हणजे कोणीही बदलायचा हेतू नसलेली CSS पकडली जाईल.

आणि काय assert करायचे याचा एकच नियम: user जसे विचारतो तसे विचारा. "Enrol नावाचे button", "Name असे label असलेले field" — .btn-primary किंवा #f3 > div:nth-child(2) नाही. User च्या भाषेत लिहिलेले tests redesigns मधून टिकतात आणि accessibility तपासणी म्हणूनही काम करतात: test ला control त्याच्या नावाने सापडत नसेल, तर screen reader लाही सापडत नाही (धडा 06).

🗺️ आकृती

flowchart TB
    u["🔬 unit — many, milliseconds<br/>StudentCard(s) puts the name in"]
    c["🧩 component — some<br/>the form renders, the button is named Enrol"]
    e["🧭 end-to-end — few, slow<br/>a real browser enrols a student"]
    v["📸 visual — a safety net<br/>screenshot diffs catch unintended CSS"]
    u --> c --> e --> v
    rule["assert by role and label — never by class name"]

❓ काय

Pyramid: तळाशी खूप स्वस्त tests, वर थोडे महाग. उलटे pyramids (सगळे end-to-end) मंद आणि flaky असतात; वरचा भागच नसेल तर integration bugs पुढे जातात.
Tools: Vitest/Jest (unit), Testing Library (component — त्याचे संपूर्ण तत्त्वज्ञान getByRole/getByLabelText आहे), Playwright किंवा Cypress (end-to-end), Playwright/Percy (visual).
आपली dependency-शिवायची आवृत्ती: ui/smoke_test.py page fetch करतो आणि रचनेवर assert करतो (lang, एकच h1, inputs साठी labels, images वर alt, skip link, live region), CSS मधले tokens, आणि API च्या यश आणि अपयशाचे आकार. दहा तपासण्या, एक exit code — CI साठी अगदी योग्य.
CI मध्ये (CI/CD शाळा): server सुरू करा, तपासण्या चालवा, non-zero exit वर build fail करा.
Accessibility testing: library म्हणून axe-core, किंवा CI मध्ये Lighthouse — automated tools साधारण एक तृतीयांश पकडतात; बाकीचे keyboard वरून केलेली फेरी पकडते.
Flakiness: ठराविक milliseconds साठी कधीच थांबू नका, परिस्थितीची (एखादा element दिसण्याची) वाट पाहा.

🤔 का

कारण UI हा लोक सगळ्यात जास्त वेळा बदलतात आणि ज्यावर सगळ्यात कमी विश्वास ठेवतात असा थर आहे, आणि "मी इकडेतिकडे click केले आणि ठीक दिसले" हे एका माणसापलीकडे चालत नाही. दोन सेकंदांत चालणारा दहा-तपासण्यांचा smoke test लाजिरवाण्या प्रकारचे bugs थांबवतो: हरवलेले label, मोडलेला endpoint, token मधली typo.

🔧 कसे (या repo मध्ये)

ui/smoke_test.py फक्त urllib आणि re वापरतो: तो HTML चे semantics, CSS चे tokens आणि focus style assert करतो, आणि API ला दोनदा hit करतो — एकदा students ची अपेक्षा ठेवून, एकदा चुकीच्या form साठी 400 ची अपेक्षा ठेवून. ui/tests/board.spec.js तेच दोन प्रवास Playwright मध्ये दाखवतो, getByRole आणि getByLabel वापरून लिहिलेले.

🧪 करून पाहा

python3 ui/mock_api.py &
python3 ui/smoke_test.py; echo "exit code: $?"          # 🎉 the board stands · 0
# 1) break something and watch it fail:
#    remove alt="" from the card <img> in index.html → ❌ images have alt, exit 1
# 2) add YOUR check to smoke_test.py (3 lines): the enrol form has a submit button
#    check("form has a submit button", 'type="submit"' in html)
# 3) add a check that the dark theme tokens exist for [data-theme="dark"]
# 4) read ui/tests/board.spec.js and notice: getByRole('button', {name: 'Enrol'}), getByLabel('Name') —
#    the same words a screen reader would say

✅ तपासा — तुम्हाला काय दिसायला हवे

निरोगी फलकावर 🎉 the board stands आणि exit code 0; alt काढल्यावर नाव असलेली ❌ ओळ आणि exit 1. तुमच्या दोन नवीन तपासण्या यादीत दिसतात आणि pass होतात.

🏁 तुम्ही आत्ताच काय सिद्ध केले

दहा सेकंदांच्या तपासण्या सगळ्यात जास्त त्रास देणाऱ्या चुका पकडतात, आणि user च्या भाषेत लिहिलेले tests accessibility tests म्हणूनही काम करतात.

⚠️ नेहमीच्या चुका

class names किंवा DOM paths वर assert करणे — प्रत्येक redesign suite मोडतो
फक्त end-to-end tests (मंद, flaky) किंवा फक्त unit tests (integration bugs पुढे जातात)
परिस्थितीची वाट पाहण्याऐवजी sleep(2000)
मोठ्या HTML गठ्ठ्यांचे snapshot tests, जे बदलल्यावर कोणीच वाचत नाही
तुमच्या वागणुकीऐवजी framework test करणे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: सगळ्यात वारंवार होणारे, सगळ्यात जास्त दिसणारे regressions front end मध्येच राहतात. CI मधला छोटासा smoke test हा कोणीही UI repo मध्ये जोडू शकणारे सगळ्यात मौल्यवान testing आहे — म्हणूनच हा repo त्याच्यासह येतो.

⏭️ पुढे

फलक test झाला आहे; आता त्याला जगाशी सुरक्षितपणे बोलू द्या: backends शी बोलणे — CORS, tokens, loading आणि error states, XSS.

git checkout lesson-11-talking-to-backends

🧪 Lesson 10 — Testing UI: does the board still stand?

📍 You are here: Lesson 10 of 12 · Previous: lesson-09-performance · Next: lesson-11-talking-to-backends

📦 What's in this branch

Lessons 01–09, plus how to change the board without breaking it: the test pyramid for UI (unit, component, end-to-end, visual), what to assert (roles and labels, not class names), and the zero-dependency smoke test that already guards this repo. Real files:

ui/smoke_test.py — ten checks, no dependencies
ui/tests/board.spec.js — the same intent in Playwright

🧒 Explain like I'm 5

Before anyone repaints the board, someone should check it still works. There are four kinds of check, and you want different amounts of each:

Unit 🔬 — test a pure function on its own. StudentCard(s) with test data: does it put the name in? Fast, plentiful.
Component 🧩 — render a piece with fake data and assert on the DOM ("there is a button named Enrol"). Still fast; catches real wiring.
End-to-end 🧭 — a real browser opens the board, fills the form, clicks Enrol, and checks the card appears. Slow, occasionally flaky, priceless. Keep a handful of golden paths.
Visual 📸 — screenshot the board and diff it against yesterday's, to catch the CSS nobody meant to change.

And the one rule for what to assert: ask the way a user asks. "The button named Enrol", "the field labelled Name" — not .btn-primary or #f3 > div:nth-child(2). Tests written in user language survive redesigns and double as an accessibility check: if the test cannot find the control by its name, neither can a screen reader (lesson 06).

🗺️ Diagram

flowchart TB
    u["🔬 unit — many, milliseconds<br/>StudentCard(s) puts the name in"]
    c["🧩 component — some<br/>the form renders, the button is named Enrol"]
    e["🧭 end-to-end — few, slow<br/>a real browser enrols a student"]
    v["📸 visual — a safety net<br/>screenshot diffs catch unintended CSS"]
    u --> c --> e --> v
    rule["assert by role and label — never by class name"]

❓ What

The pyramid: many cheap tests at the bottom, a few expensive ones at the top. Inverted pyramids (all end-to-end) are slow and flaky; no top at all means integration bugs ship.
Tools: Vitest/Jest (unit), Testing Library (component — its whole philosophy is getByRole/getByLabelText), Playwright or Cypress (end-to-end), Playwright/Percy (visual).
Our zero-dependency version: ui/smoke_test.py fetches the page and asserts on structure (lang, one h1, labels for inputs, alt on images, the skip link, the live region), the tokens in the CSS, and the API's success and failure shapes. Ten checks, one exit code — perfect for CI.
In CI (the CI/CD school): start the server, run the checks, fail the build on a non-zero exit.
Accessibility testing: axe-core as a library, or Lighthouse in CI — automated tools catch roughly a third; the keyboard pass catches the rest.
Flakiness: wait for conditions (an element appearing), never for a fixed number of milliseconds.

🤔 Why

Because UI is the layer people change most often and trust least, and because "I clicked around and it looked fine" does not scale past one person. A ten-check smoke test that runs in two seconds prevents the embarrassing class of bug: a missing label, a broken endpoint, a typo in a token.

🔧 How (in this repo)

ui/smoke_test.py uses only urllib and re: it asserts the HTML's semantics, the CSS's tokens and focus style, and hits the API twice — once expecting students, once expecting a 400 for a bad form. ui/tests/board.spec.js shows the same two journeys in Playwright, written with getByRole and getByLabel.

🧪 Try it

python3 ui/mock_api.py &
python3 ui/smoke_test.py; echo "exit code: $?"          # 🎉 the board stands · 0
# 1) break something and watch it fail:
#    remove alt="" from the card <img> in index.html → ❌ images have alt, exit 1
# 2) add YOUR check to smoke_test.py (3 lines): the enrol form has a submit button
#    check("form has a submit button", 'type="submit"' in html)
# 3) add a check that the dark theme tokens exist for [data-theme="dark"]
# 4) read ui/tests/board.spec.js and notice: getByRole('button', {name: 'Enrol'}), getByLabel('Name') —
#    the same words a screen reader would say

✅ Verify — what you should see

🎉 the board stands and exit code 0 on a healthy board; a named ❌ line and exit 1 after you remove the alt. Your two new checks appear in the list and pass.

🏁 What you just proved

Ten seconds of checks catch the mistakes that hurt most, and tests written in user language double as accessibility tests.

⚠️ Common mistakes

asserting on class names or DOM paths — every redesign breaks the suite
only end-to-end tests (slow, flaky) or only unit tests (integration bugs ship)
sleep(2000) instead of waiting for a condition
snapshot tests of giant HTML blobs that nobody reads when they change
testing the framework instead of your behaviour

🏭 Why this matters in production: the front end is where the most frequent, most visible regressions live. A tiny smoke test in CI is the highest-value testing anyone adds to a UI repo — it is why this one ships with it.

⏭️ Next

The board is tested; now make it talk to the world safely: talking to backends — CORS, tokens, loading and error states, XSS.

git checkout lesson-11-talking-to-backends

← Previousperformance Next →talking to backends

This page is the lesson's README from the lesson-10-testing branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.