testing-blocks（测试块）

Testing Blocks

This skill guides you through testing code changes in AEM Edge Delivery Services projects. Testing follows a value-versus-cost philosophy: create and maintain tests when the value they bring exceeds the cost of creation and maintenance.

Related Skills

• content-driven-development: Test content created during CDD serves as the basis for testing
• building-blocks: This skill is automatically invoked after block implementation
• block-collection-and-party: May provide reference test patterns from similar blocks

When to Use This Skill

Use this skill:

• ✅ After implementing or modifying blocks
• ✅ After changes to core scripts (scripts.js, delayed.js, aem.js)
• ✅ After style changes (styles.css, lazy-styles.css)
• ✅ After configuration changes that affect functionality
• ✅ Before opening any pull request with code changes

This skill should be automatically invoked by the building-blocks skill after implementation is complete.

Testing Philosophy: Value vs Cost

The Principle: Create and maintain tests when the value they bring exceeds the cost of creation and maintenance.

Keeper Tests (High Value, Worth Maintaining)

✅ Write unit tests for:

• Logic-heavy utility functions used across multiple blocks
• Data processing and transformation logic
• API integrations and external service interactions
• Complex algorithms or business logic
• Shared libraries and helper functions

These tests provide lasting value because they catch regressions in reused code, serve as living documentation, and are fast and easy to maintain.

Throwaway Tests (Lower Value, Use Once)

⚠️ Use browser tests for:

• Block decoration logic (DOM transformations)
• Specific DOM structures or UI layouts
• Visual appearance validation
• Block-specific rendering behavior

These tests are better done in a browser because DOM structures change frequently, visual validation requires human judgment, and maintaining UI tests is expensive relative to their value.

Important: Even throwaway tests have value! Use them to:

1. Validate your implementation works correctly
2. Take screenshots to evaluate visual correctness
3. Show screenshots to humans for feedback
4. Include screenshots in PRs to aid review

Organization: Keep throwaway tests in test/tmp/ and test content in drafts/tmp/. Both directories should be gitignored so temporary test artifacts aren't committed.

Testing Checklist

Before opening a pull request, complete ALL of the following:

• Existing tests pass - All keeper tests still pass with your changes
• Unit tests written - New keeper tests for any logic-heavy utilities or data processing
• Browser validation - Feature tested in local dev server, screenshots captured
• All variants tested - Each variant/configuration of blocks validated
• Responsive behavior - Tested on mobile, tablet, desktop viewports
• Linting passes - npm run lint completes without errors
• Branch pushed - Code committed and pushed to feature branch
• GitHub checks verified - Use gh checks to confirm all CI checks pass

Testing Methods Overview

1. Unit Tests (KEEPER TESTS)

When to use: Logic-heavy functions, utilities, data processing, API integrations

Quick start:

# Verify test setup (see resources/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');
  });
});

# Run tests during development
npm run test:watch

Detailed guide: See resources/unit-testing.md

2. Browser Testing (THROWAWAY TESTS)

When to use: Block decoration, visual validation, DOM structure, responsive design

Organization:

• Test scripts: test/tmp/test-{block}-browser.js
• Test content: drafts/tmp/{block}.html
• Screenshots: test/tmp/screenshots/
• Both test/tmp/ and drafts/tmp/ should be gitignored

Quick start:

# Install Playwright
npm install --save-dev playwright
npx playwright install chromium

# Create test content
# drafts/tmp/my-block.html (copy head.html content, add test markup)

# Start dev server with drafts folder
aem up --html-folder drafts

# Create throwaway test script in test/tmp/
# test/tmp/test-my-block.js
import { chromium } from 'playwright';
import { mkdir } from 'fs/promises';

async function test() {
  await mkdir('./test/tmp/screenshots', { recursive: true });
  const browser = await chromium.launch({ headless: false });
  const page = await browser.newPage();

  await page.goto('http://localhost:3000/drafts/tmp/my-block');
  await page.waitForSelector('.my-block');
  await page.screenshot({
    path: './test/tmp/screenshots/my-block.png',
    fullPage: true
  });

  await browser.close();
}

test().catch(console.error);

# Run the test
node test/tmp/test-my-block.js

# Clean up when done (optional - gitignored either way)
rm -rf test/tmp/*

Detailed guide: See resources/browser-testing.md

3. Linting (ALWAYS)

When to use: Before every commit

Quick start:

# Run linting
npm run lint

# Auto-fix issues
npm run lint:fix

Linting MUST pass before opening a PR. Non-negotiable.

4. Performance Testing (AUTOMATED)

When to use: After pushing branch, automatically via GitHub checks

Quick start:

# Push branch
git push -u origin your-branch

# Create PR with test link
# PR description MUST include:
# Preview: https://branch--repo--owner.aem.page/path/to/test

# Monitor checks
gh pr checks --watch

Performance tests run automatically when you include a test link in your PR description.

Complete Workflow

For detailed step-by-step workflow, see resources/testing-workflow.md.

Quick summary:

During Development

1. Write unit tests for new utilities
2. Run npm run test:watch
3. Manually test in browser

Before Committing

1. Run npm test - all tests pass
2. Run npm run lint - linting passes
3. Write throwaway browser test in test/tmp/
4. Create test content in drafts/tmp/
5. Review screenshots from test/tmp/screenshots/
6. Manual validation in browser

Before Opening PR

1. Commit and push to feature branch (test/tmp/ won't be included)
2. Verify branch preview loads
3. Run gh checks
4. Create PR with test link
5. Monitor gh pr checks

After PR Review

1. Address feedback
2. Re-test
3. Verify checks pass

Troubleshooting

For detailed troubleshooting guide, see resources/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

GitHub checks fail

• Ensure PR has test link
• Check gh pr checks for details
• Fix performance issues if PSI fails

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: resources/unit-testing.md - Complete guide to writing and maintaining unit tests
• Browser Testing: resources/browser-testing.md - Playwright/Puppeteer workflows and best practices
• Testing Workflow: resources/testing-workflow.md - Step-by-step workflow from dev to PR
• Troubleshooting: resources/troubleshooting.md - Solutions to common testing issues
• Vitest Setup: resources/vitest-setup.md - One-time configuration guide

Integration with Building Blocks Skill

The building-blocks skill automatically invokes this skill after implementation.

Expected flow:

1. Building blocks completes implementation
2. Invokes testing-blocks skill
3. This skill guides testing process
4. Returns control when testing complete

Building blocks provides:

• Block name being tested
• Test content URL from CDD process
• Any variants that need testing

This skill returns:

• Confirmation all tests pass
• Screenshots from browser testing (if requested)
• Any issues discovered during testing

Summary

Testing in AEM Edge Delivery follows a pragmatic value-versus-cost approach:

Create keeper tests for:

• Logic-heavy utilities
• Data processing and transformations
• API integrations
• Shared libraries

Use throwaway browser tests for:

• Block decoration validation
• Visual appearance
• DOM structure
• Interactive behavior

Always do:

• Run linting before commits
• Test manually in browser
• Verify GitHub checks pass
• Include test links in PRs

Remember: The goal is confidence that your code works correctly, not achieving 100% test coverage. Write tests that provide value, and validate everything else in a browser.