await page.locator('.my-block').screenshot({ path: 'desktop-block.png' });

// Check for console errors page.on('console', msg => console.log('Browser:', msg.text()));

await browser.close(); }

test().catch(console.error);

Run: `node test-my-block.js` then delete the script and analyze the resulting artifacts.

**Option 3: Manual browser testing**

Use a standard web browser with dev tools:
1. Navigate to test content: `http://localhost:3000/path/to/test/content`
2. Use browser dev tools responsive mode to test viewports:
   - Mobile: <600px (e.g., 375px)
   - Tablet: 600-900px (e.g., 768px)
   - Desktop: >900px (e.g., 1200px)
3. Check console for errors at each viewport
4. Take screenshots as proof (browser screenshot tool or dev tools)

### Validation Against Acceptance Criteria

**If acceptance criteria provided (from CDD Step 2):**
- Review each criterion
- Test specific scenarios mentioned
- Verify all criteria are met

**If design/mockup screenshots provided:**
- Compare implementation to design
- Verify visual alignment
- Note any intentional deviations

### Proof of Testing

**You must provide:**
- ✅ Screenshots of test content in browser (at least one viewport)
- ✅ Confirmation no console errors
- ✅ Confirmation acceptance criteria met (if provided)

**Success criteria:**
- ✅ All test content loads and renders correctly
- ✅ Responsive behavior validated across viewports
- ✅ No console errors
- ✅ Screenshots captured as proof
- ✅ Acceptance criteria validated (if provided)

**Mark complete when:** Browser testing complete with screenshots as proof

---

## Step 3: Unit Tests (Optional)

**Determine if unit tests are needed for this change.**

**Write unit tests when:**
- ✅ Logic-heavy functions (calculations, transformations)
- ✅ Utility functions used across multiple blocks
- ✅ Data processing or API integrations
- ✅ Complex business logic

**Skip unit tests when:**
- ❌ Simple DOM manipulation
- ❌ CSS-only changes
- ❌ Straightforward decoration logic
- ❌ Changes easily validated in browser

**For guidance on what to test:** See [references/testing-philosophy.md](references/testing-philosophy.md)

**If unit tests needed:**

```bash
# Verify test setup (see references/vitest-setup.md if not configured)
npm test

# Write test for utility function
# test/utils/my-utility.test.js
import { describe, it, expect } from 'vitest';
import { myUtility } from '../../scripts/utils/my-utility.js';

describe('myUtility', () => {
  it('should transform input correctly', () => {
    expect(myUtility('input')).toBe('OUTPUT');
  });
});

For detailed unit testing guidance: See references/unit-testing.md

Success criteria:

• ✅ Unit tests written for logic-heavy code
• ✅ Tests pass: npm test
• ✅ OR determined unit tests not needed

Mark complete when: Unit tests written and passing, or determined not needed

Step 4: Run Existing Tests

Verify your changes don't break existing functionality:

npm test

If tests fail:

1. Read error message carefully
2. Run single test to isolate: npm test -- path/to/test.js
3. Fix code or update test if expectations changed
4. Re-run full test suite

Success criteria:

• ✅ All existing tests pass
• ✅ No regressions introduced

Mark complete when: npm test passes with no failures

Troubleshooting

For detailed troubleshooting guide, see references/troubleshooting.md.

Common issues:

Tests fail

• Read error message carefully
• Run single test: npm test -- path/to/test.js
• Fix code or update test

Linting fails

• Run npm run lint:fix
• Manually fix remaining issues

Browser tests fail

• Verify dev server running: aem up --html-folder drafts
• Check test content exists in drafts/tmp/
• Verify URL uses /tmp/ path: http://localhost:3000/drafts/tmp/my-block
• Add waits: await page.waitForSelector('.block')

Resources

• Unit Testing: references/unit-testing.md - Complete guide to writing and maintaining unit tests
• Troubleshooting: references/troubleshooting.md - Solutions to common testing issues
• Vitest Setup: references/vitest-setup.md - One-time configuration guide
• Testing Philosophy: references/testing-philosophy.md - Guide on what and how to test

Integration with Building Blocks Skill

The building-blocks skill invokes this skill during Step 5 (Test Implementation).

Inputs received from building-blocks:

• Block name being tested
• Test content URL(s) (from CDD Step 4)
• Any variants that need testing
• Screenshots of existing implementation/design/mockup to verify against (if provided)
• Acceptance criteria to verify (from CDD Step 2)

Expected outputs to return to building-blocks:

• ✅ Confirmation all testing steps complete
• ✅ Screenshots from browser testing as proof
• ✅ Confirmation linting passes
• ✅ Confirmation tests pass
• ✅ Any issues discovered and resolved