Chapter 41: Debugging & Testing
Debugging & Testing
These two skills are what separate:
- developers who spend 4 hours wondering “why isn’t this working?”
- from developers who find the bug in 10 minutes and move on to building cool features
Debugging = finding and fixing bugs (why something is broken) Testing = making sure things don’t break in the future (proving it works correctly)
Both are non-negotiable in 2026 — especially when you start working in teams, on real products, or freelancing for clients who expect zero bugs.
Let’s go very slowly, step by step — like I’m your senior mentor showing you exactly how pros do it every day.
1. Debugging – The Art of Finding Why It’s Broken
Debugging is detective work. You gather clues, form hypotheses, test them, and eliminate possibilities until you find the real culprit.
Most Common Places Bugs Hide (2026 Reality)
| Place | Typical symptoms | How to find it quickly (your best tools) |
|---|---|---|
| HTML structure | Element not showing, wrong styles applied | Elements panel + hover → see box model & computed styles |
| CSS specificity / cascade | Style not applying even though you wrote it | Computed tab → see which rule won & why |
| JavaScript logic | Button doesn’t work, console errors | Console + Sources + breakpoints (debugger) |
| Network / loading | Images missing, API call fails | Network tab → filter XHR/Fetch + status codes |
| Responsive issues | Layout breaks only on mobile | Toggle device toolbar + responsive mode |
| Performance | Page feels laggy, high CPU | Performance tab → record & see long tasks |
| Accessibility | Screen reader skips something | Accessibility tab + screen reader (VoiceOver/NVDA) |
Your Daily Debugging Toolkit (Chrome DevTools 2026)
- Elements panel → right-click any element → Inspect → see HTML + applied CSS + box model + computed values → edit CSS live to test fixes instantly
- Console → the heart of debugging
- console.log(variable) — old-school but still king
- console.table(array) — beautiful for objects/arrays
- debugger; — pause execution right there
- $0 — currently selected element in Elements panel
- Sources → set breakpoints → click line number → refresh page → code pauses → inspect variables step-by-step
- Network → see all requests → filter “Fetch/XHR” → check status, response time, payload → right-click → “Copy as fetch” to replay in console
- Performance → record 5–10 seconds of interaction → look for long “Task” blocks (>50 ms) → main-thread blocking
- Lighthouse → run audit (Performance, Accessibility, Best Practices, SEO) → gives score + specific fixes
2. Real Debugging Example – “Why isn’t my button working?”
index.html
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Debug Me</title> <link rel="stylesheet" href="style.css"> </head> <body> <div class="container"> <button id="submitBtn">Submit Form</button> <p id="message">Waiting...</p> </div> <script src="script.js"></script> </body> </html> |
style.css
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
button { padding: 12px 24px; background: #3b82f6; color: white; border: none; border-radius: 8px; font-size: 1.1rem; cursor: pointer; } button:hover { background: #2563eb; } |
script.js (has a bug — let’s find it)
|
0 1 2 3 4 5 6 7 8 9 |
document.getElementById('submitBtn').addEventListener('click', () => { document.getElementById('message').textContent = 'Form submitted!'; console.log('Button clicked!'); }); |
Bug scenario: You click the button → nothing happens, no message change, no console log.
How to debug it step-by-step (real workflow):
- Open DevTools (F12 or right-click → Inspect)
- Check Console first → any red errors? → If yes → read them carefully (most bugs die here)
- Elements tab → click the button → see if id=”submitBtn” exists → typo? wrong id? duplicate id?
- Console → type document.getElementById(‘submitBtn’) → does it return the button element? → If null → id is wrong or script runs before DOM is ready
- Sources tab → open script.js → click line number next to addEventListener → set breakpoint (blue marker) → refresh page → click button → code pauses → check Scope → see variables
- Common fixes:
- Script in <head> without defer → DOM not ready → use <script defer> or move to end of <body>
- Typo in id → submitBtn vs submitbtn
- Multiple elements with same id → only first one is found
Fixed version (add defer or move script):
|
0 1 2 3 4 5 6 7 8 9 10 11 |
<script defer src="script.js"></script> <!-- or --> <body> ... content ... <script src="script.js"></script> </body> |
3. Testing – Proving It Works & Stays Working
Testing = writing code that checks your code.
Two main types beginners should know:
Manual Testing (you do it every day)
- Resize browser → check mobile/tablet/desktop
- Keyboard only (Tab → Enter) → can you use everything?
- Screen reader (VoiceOver / NVDA) → does it read logically?
- Lighthouse audit → run every release
- Slow 3G mode in DevTools → does it still feel usable?
Automated Testing (the pro level)
-
Unit tests → test small pieces of JS logic Tool: Vitest / Jest
JavaScript012345678910111213// sum.jsexport function sum(a, b) { return a + b; }// sum.test.jsimport { sum } from './sum';test('adds 1 + 2 to equal 3', () => {expect(sum(1, 2)).toBe(3);}); -
Component tests → test UI components (React/Vue/Svelte) Tool: Vitest + Testing Library
-
End-to-end (E2E) tests → test real user flows Tool: Playwright or Cypress
JavaScript012345678910111213// example.spec.js (Playwright)test('login works', async ({ page }) => {await page.goto('https://myapp.com/login');await page.fill('#email', 'test@example.com');await page.fill('#password', 'password123');await page.click('button[type=submit]');await expect(page).toHaveURL(/dashboard/);});
Quick Debugging & Testing Mastery Checklist (2026 Beginner)
- Always open DevTools first when something breaks
- Console is your best friend — log everything suspicious
- Learn breakpoints in Sources tab — step through code
- Run Lighthouse after every major change
- Test keyboard navigation weekly
- Test on real mobile device monthly (not just emulation)
- Write 1–2 simple Jest/Vitest tests for important functions
- Never commit code without checking Console for errors/warnings
How does it feel when you find a bug in 2 minutes instead of 2 hours? That moment is when you become a confident developer.
Next possible lessons — tell me what you want:
- “Step-by-step DevTools debugging workflow for CSS/JS bugs”
- “How to write your first Jest unit tests”
- “Playwright E2E testing crash course”
- “Common bugs in responsive design & how to catch them”
- “Debugging performance issues with Lighthouse + Performance tab”
You’re now learning the real engineering side of web development. Chai khatam? Fresh cup lao — let’s debug & test! 🚀 🔍 😄
