Merge pull request 'Project Cleanup and Organization' (#26) from adilallo/maintenance/ProjectOrganization into main

Reviewed-on: #26
This commit was merged in pull request #26.
This commit is contained in:
2026-01-27 00:08:43 +00:00
90 changed files with 173 additions and 53835 deletions
+27 -77
View File
@@ -1,86 +1,42 @@
# Testing Documentation
# Documentation Index
This directory contains comprehensive testing documentation for the CommunityRule platform.
This directory contains all project documentation organized by topic.
## 📚 Documentation Structure
### 1. [testing-framework.md](./testing-framework.md) - **Main Guide**
### Guides (`guides/`)
**Complete testing framework documentation** covering all aspects of testing:
Comprehensive guides for different aspects of the project:
- Testing architecture and philosophy
- Unit, integration, and E2E testing
- Visual regression testing
- Accessibility testing
- Performance testing
- CI/CD pipeline
- Development workflow
- Best practices and troubleshooting
#### Testing
- **[testing.md](./guides/testing.md)** - Complete testing strategy and philosophy
- **[testing-framework.md](./guides/testing-framework.md)** - Detailed testing framework documentation
- **[testing-quick-reference.md](./guides/testing-quick-reference.md)** - Quick reference for daily development
- **[visual-regression.md](./guides/visual-regression.md)** - Visual regression testing guide
**Use this for**: Learning the testing framework, understanding architecture, comprehensive reference
#### Performance
- **[performance.md](./guides/performance.md)** - Performance optimization and monitoring guide
### 2. [testing-quick-reference.md](./testing-quick-reference.md) - **Quick Reference**
#### Content
- **[content-creation.md](./guides/content-creation.md)** - Content creation guidelines
**Essential commands and quick troubleshooting** for daily development:
- Essential test commands
- Current test status and metrics
- Common test patterns
- Troubleshooting solutions
- Performance budgets
- CI/CD pipeline overview
**Use this for**: Daily development, quick commands, troubleshooting, reference
### 3. [visual-regression-guide.md](./visual-regression-guide.md) - **Visual Testing Guide**
**Focused guide for visual regression testing**:
- Visual regression workflow
- Snapshot management
- Configuration and best practices
- Troubleshooting visual test issues
- CI/CD integration for visual tests
**Use this for**: Visual regression testing, snapshot management, visual test troubleshooting
### 4. [performance-optimization-guide.md](./performance-optimization-guide.md) - **Performance Guide**
**Comprehensive performance optimization documentation**:
- Performance targets and metrics
- Frontend optimizations (React.memo, code splitting, image optimization)
- Performance monitoring and bundle analysis
- Web Vitals tracking and dashboard
- Performance testing and troubleshooting
- Best practices and optimization strategies
**Use this for**: Performance optimization, monitoring, bundle analysis, Web Vitals tracking
## 🎯 How to Use These Documents
## 🎯 Quick Navigation
### For New Team Members
1. Start with **testing-framework.md** to understand the complete testing strategy
2. Use **testing-quick-reference.md** for daily development
3. Reference **visual-regression-guide.md** when working with visual tests
4. Review **performance-optimization-guide.md** for performance optimization
1. Start with **[testing.md](./guides/testing.md)** to understand the testing strategy
2. Use **[testing-quick-reference.md](./guides/testing-quick-reference.md)** for daily development
3. Reference **[performance.md](./guides/performance.md)** for performance optimization
### For Daily Development
- **[testing-quick-reference.md](./guides/testing-quick-reference.md)** - Essential commands and troubleshooting
- **[testing-framework.md](./guides/testing-framework.md)** - Detailed testing explanations
1. Use **testing-quick-reference.md** for commands and troubleshooting
2. Reference **testing-framework.md** for detailed explanations
3. Use **visual-regression-guide.md** for visual test workflows
4. Use **performance-optimization-guide.md** for performance monitoring
### For Specific Topics
- **Visual Testing**: [visual-regression.md](./guides/visual-regression.md)
- **Performance**: [performance.md](./guides/performance.md)
- **Content**: [content-creation.md](./guides/content-creation.md)
### For Troubleshooting
1. Check **testing-quick-reference.md** for common solutions
2. Use **testing-framework.md** for detailed troubleshooting
3. Reference **visual-regression-guide.md** for visual test issues
4. Use **performance-optimization-guide.md** for performance issues
## 📊 Current Testing Status
## 📊 Current Project Status
- **Unit Tests**: 94.88% coverage (exceeds 85% target)
- **Integration Tests**: 5 comprehensive test suites
@@ -90,17 +46,10 @@ This directory contains comprehensive testing documentation for the CommunityRul
- **Performance**: Lighthouse CI with budgets
- **Bundle Analysis**: Real-time monitoring with budgets
- **Web Vitals Tracking**: Core Web Vitals collection
- **Performance Optimization**: React.memo + code splitting
## 🔄 Documentation Updates
This documentation is maintained by the CommunityRule development team and updated regularly to reflect:
- Current testing framework status
- Best practices and patterns
- Troubleshooting solutions
- CI/CD pipeline changes
- New testing features
This documentation is maintained by the CommunityRule development team and updated regularly.
## 📚 Additional Resources
@@ -108,8 +57,9 @@ This documentation is maintained by the CommunityRule development team and updat
- **Playwright Documentation**: https://playwright.dev/
- **React Testing Library**: https://testing-library.com/
- **Lighthouse CI**: https://github.com/GoogleChrome/lighthouse-ci
- **Next.js Documentation**: https://nextjs.org/docs
---
**Last Updated**: December 2024
**Last Updated**: January 2025
**Maintained by**: CommunityRule Development Team
-275
View File
@@ -1,275 +0,0 @@
# Testing Quick Reference
## 🚀 Essential Commands
### Daily Development
```bash
# Run all tests
npm test
# Watch mode (during development)
npm run test:watch
# E2E tests
npm run e2e
# Performance check
npm run lhci
```
### Manual Runner Management
```bash
# Start runner (before creating PR)
./start-runner.sh
# Check runner status
./status-runner.sh
# Stop runner (after PR complete)
./stop-runner.sh
```
### Visual Regression
```bash
# Update baselines after intentional changes
npx playwright test tests/e2e/visual-regression.spec.ts --update-snapshots
# Check for visual changes
npx playwright test tests/e2e/visual-regression.spec.ts
```
### Debugging
```bash
# Debug unit tests
npm run test:ui
# Debug E2E tests
npm run e2e:ui
# Debug with browser
npx playwright test --debug
```
## 📝 Writing Tests
### Unit Test Template
```jsx
// tests/unit/Component.test.jsx
import { render, screen } from "@testing-library/react";
import { describe, test, expect, afterEach } from "vitest";
import { cleanup } from "@testing-library/react";
import Component from "../../app/components/Component";
describe("Component", () => {
afterEach(() => cleanup());
test("renders correctly", () => {
render(<Component />);
expect(screen.getByRole("button")).toBeInTheDocument();
});
});
```
### E2E Test Template
```typescript
// tests/e2e/feature.spec.ts
import { test, expect } from "@playwright/test";
test.describe("Feature", () => {
test.beforeEach(async ({ page }) => {
await page.goto("/");
});
test("should work correctly", async ({ page }) => {
await expect(page).toHaveTitle(/CommunityRule/);
await expect(page.locator("h1")).toBeVisible();
});
});
```
## 🔧 Common Testing Patterns
### Testing User Interactions
```jsx
// Unit test
import userEvent from "@testing-library/user-event";
test("handles user input", async () => {
const user = userEvent.setup();
render(<Form />);
await user.type(screen.getByLabelText("Email"), "test@example.com");
await user.click(screen.getByRole("button", { name: "Submit" }));
expect(screen.getByText("Success")).toBeInTheDocument();
});
```
### Testing Async Operations
```jsx
// Unit test
test("loads data", async () => {
render(<DataComponent />);
expect(screen.getByText("Loading...")).toBeInTheDocument();
await waitFor(() => {
expect(screen.getByText("Data loaded")).toBeInTheDocument();
});
});
```
### Testing Accessibility
```typescript
// E2E test
import { runA11y } from "./axe";
test("meets accessibility standards", async ({ page }) => {
await page.goto("/");
const violations = await runA11y(page);
expect(violations).toEqual([]);
});
```
## 🎯 Test Coverage Targets
- **Lines**: 85%
- **Functions**: 85%
- **Statements**: 85%
- **Branches**: 80%
## 🚨 Common Issues & Solutions
### Unit Tests
```bash
# Issue: JSX not parsing in .js files
# Solution: Ensure vitest.config.js has proper esbuild config
# Issue: Component not rendering
# Solution: Check imports and component exports
# Issue: Test cleanup errors
# Solution: Add afterEach(cleanup()) to test suites
```
### E2E Tests
```bash
# Issue: Element not found
# Solution: Use semantic selectors (role, text, label)
# Issue: Test timeout
# Solution: Add proper waitFor or waitForLoadState
# Issue: Multiple elements with same selector
# Solution: Use .first(), .nth(), or more specific selectors
```
### Visual Regression
```bash
# Issue: Screenshots don't match
# Solution: Check if changes are intentional, then update baselines
# Issue: Elements not visible
# Solution: Ensure elements are in viewport before screenshot
```
## 📊 Performance Budgets
### Lighthouse CI Targets
- **Performance Score**: >90
- **Accessibility Score**: >95
- **Best Practices**: >90
- **SEO Score**: >90
### Core Web Vitals
- **LCP**: <2.5s
- **FID**: <100ms
- **CLS**: <0.1
## 🔄 CI/CD Pipeline Jobs
1. **Unit Tests** (Node 18, 20)
2. **E2E Tests** (Chromium, Firefox, WebKit)
3. **Visual Regression Tests**
4. **Performance Tests**
5. **Storybook Tests**
6. **Lint & Format**
7. **Build Verification**
## 📁 Test File Structure
```
tests/
├── unit/ # Component tests
│ ├── Button.test.jsx
│ ├── HeroBanner.test.jsx
│ └── ...
├── integration/ # Integration tests
│ └── ContentLockup.integration.test.jsx
└── e2e/ # E2E tests
├── homepage.spec.ts
├── user-journeys.spec.ts
├── edge-cases.spec.ts
└── visual-regression.spec.ts
```
## 🎨 Visual Regression Screenshots
### Generated Screenshots
- Full page (mobile, tablet, desktop)
- Component sections (hero, logo wall, cards)
- Interactive states (hover, focus, loading)
- Special modes (dark, high contrast, reduced motion)
### Managing Changes
```bash
# Intentional changes
npx playwright test tests/e2e/visual-regression.spec.ts --update-snapshots
# Review changes
npx playwright test tests/e2e/visual-regression.spec.ts
```
## 📈 Monitoring
### Test Metrics
- **Unit Tests**: 124 tests
- **E2E Tests**: 308 tests (4 browsers)
- **Visual Screenshots**: 92 baselines
- **Coverage**: >85% target
### CI Metrics
- **Pipeline Jobs**: 7 parallel jobs
- **Execution Time**: Monitor build performance
- **Success Rate**: Track pipeline stability
- **Artifacts**: Test results and screenshots
## 🔗 Useful Links
- [Full Testing Documentation](TESTING.md)
- [Vitest Docs](https://vitest.dev/)
- [Playwright Docs](https://playwright.dev/)
- [React Testing Library](https://testing-library.com/docs/react-testing-library/intro/)
- [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci)
---
**Quick Reference Version**: December 2024
@@ -345,7 +345,7 @@ git commit -m "Update visual regression snapshots for [describe changes]"
## 🔗 Useful Links
- **Full Testing Documentation**: [docs/testing-framework.md](./testing-framework.md)
- **Full Testing Documentation**: [docs/guides/testing-framework.md](./testing-framework.md)
- **Vitest Docs**: https://vitest.dev/
- **Playwright Docs**: https://playwright.dev/
- **React Testing Library**: https://testing-library.com/docs/react-testing-library/intro/
+258
View File
@@ -0,0 +1,258 @@
# Testing Strategy for CommunityRule
## Overview
This document outlines our comprehensive testing strategy that properly separates unit testing from responsive behavior testing, following best practices for JSDOM limitations and real browser testing.
## Current Test Status
- **236 total tests** across the project
- **227 tests passing** (96.2% success rate)
- **9 tests failing** (performance and interaction tests)
- **15 test files** covering all major components
- **Performance Monitoring**: Comprehensive regression detection and budget enforcement
## Testing Philosophy
### The Problem with JSDOM and Responsive Testing
**Short take: Unit tests in JSDOM can't truly "switch breakpoints."** JSDOM doesn't evaluate CSS media queries, so Tailwind's `hidden sm:block …` won't change visibility when you "resize" the window.
### Solution: Proper Test Separation
- **Unit / component tests (Vitest + RTL):** assert **structure and classes**, not responsive visibility.
- **Responsive behavior:** verify with **browser-based tests** (Playwright) or **visual tests** (Chromatic/Storybook) at real viewport widths.
## Test Categories
### 1. Unit Tests (Vitest + React Testing Library)
**Purpose:** Test component structure, accessibility, and configuration data.
**What to test:**
- DOM roles/labels exist: `role="banner"`, nav landmark, menu items
- The right **Tailwind classes** are present on wrappers (`block sm:hidden`, `hidden md:block`, etc.)
- Data-driven bits produce the expected count/order (e.g., `navigationItems`, `avatarImages`, `logoConfig`)
- Component configuration and exported data structures
**Example:**
```javascript
// tests/unit/Header.structure.test.js
test("logo wrappers include breakpoint classes", () => {
render(<Header />);
const logoWrappers = screen.getAllByTestId("logo-wrapper");
// Check first logo variant (xs only)
expect(logoWrappers[0]).toHaveClass("block", "sm:hidden");
// Check second logo variant (sm only)
expect(logoWrappers[1]).toHaveClass("hidden", "sm:block", "md:hidden");
});
```
### 2. Browser-Based Tests (Playwright)
**Purpose:** Test real responsive behavior at actual viewport widths.
**What to test:**
- **Visibility** at real breakpoints
- **Layout changes** between breakpoints
- **Interactive behavior** at different screen sizes
- **Accessibility** across viewports
**Example:**
```javascript
// tests/e2e/header.responsive.spec.js
const breakpoints = [
{ name: "xs", width: 360, height: 700 },
{ name: "sm", width: 640, height: 700 },
{ name: "md", width: 768, height: 700 },
{ name: "lg", width: 1024, height: 700 },
{ name: "xl", width: 1280, height: 700 },
];
for (const bp of breakpoints) {
test(`header layout at ${bp.name}`, async ({ page }) => {
await page.setViewportSize({ width: bp.width, height: bp.height });
await page.goto("/");
const nav = page.getByRole("navigation", { name: /main navigation/i });
await expect(nav).toBeVisible();
});
}
```
### 3. Visual Tests (Storybook + Chromatic)
**Purpose:** Visual regression testing and design system validation.
**What to test:**
- **Visual diffs** per breakpoint
- **Design consistency** across viewports
- **Component variations** and states
**Example:**
```javascript
// stories/Header.responsive.stories.js
export default {
parameters: {
chromatic: {
viewports: [360, 640, 768, 1024, 1280],
delay: 100,
},
},
};
```
## Component Improvements
### Header Component Enhancements
1. **Added Test IDs** for easier testing:
```jsx
<div data-testid="logo-wrapper" className={config.breakpoint}>
{renderLogo(config.size, config.showText)}
</div>
```
2. **Exported Configuration** for testing:
```javascript
export const navigationItems = [...];
export const avatarImages = [...];
export const logoConfig = [...];
```
3. **Structured Breakpoint Containers**:
```jsx
<div data-testid="nav-xs" className="block sm:hidden">
<div data-testid="nav-sm" className="hidden sm:block md:hidden">
<div data-testid="nav-md" className="hidden md:block lg:hidden">
```
## Test File Structure
```
tests/
├── unit/ # Unit tests (Vitest + RTL)
│ ├── Header.test.jsx # CONSOLIDATED: Comprehensive Header tests
│ ├── Footer.test.jsx
│ ├── Layout.test.jsx
│ └── Page.test.jsx
├── integration/ # Integration tests
│ └── ContentLockup.integration.test.jsx
├── e2e/ # Browser tests (Playwright)
│ └── header.responsive.spec.js # NEW: Responsive behavior tests
└── stories/ # Storybook stories
└── Header.responsive.stories.js # NEW: Visual testing
```
## Best Practices
### Unit Testing (JSDOM)
1. **Test structure, not visibility**:
```javascript
// ✅ Good: Test classes exist
expect(element).toHaveClass("block", "sm:hidden");
// ❌ Bad: Test visibility (doesn't work in JSDOM)
expect(element).toBeVisible();
```
2. **Use test IDs for containers**:
```javascript
// ✅ Good: Test specific containers
const logoWrapper = screen.getByTestId("logo-wrapper");
// ❌ Bad: Query by complex class strings
const logoWrapper = document.querySelector(".block.sm\\:hidden");
```
3. **Test configuration data**:
```javascript
// ✅ Good: Test exported configuration
expect(navigationItems).toHaveLength(3);
expect(logoConfig).toHaveLength(5);
```
### Browser Testing (Playwright)
1. **Test real viewport sizes**:
```javascript
await page.setViewportSize({ width: 640, height: 700 });
```
2. **Test visibility at breakpoints**:
```javascript
if (bp.name === "xs") {
await expect(page.getByTestId("auth-xs")).toBeVisible();
}
```
3. **Test accessibility across viewports**:
```javascript
const interactiveElements = [
page.getByRole("link", { name: /use cases/i }),
page.getByRole("button", { name: /create rule/i }),
];
for (const element of interactiveElements) {
await expect(element).toBeVisible();
await expect(element).toBeEnabled();
}
```
## Running Tests
### Unit Tests
```bash
npm test # Run all unit tests
npm test tests/unit/ # Run only unit tests
npm test Header.structure # Run specific test file
```
### Browser Tests
```bash
npx playwright test # Run all browser tests
npx playwright test header.responsive.spec.js # Run specific test
```
### Visual Tests
```bash
npm run storybook # Start Storybook
npx chromatic --project-token=xxx # Run visual tests
```
## Future Improvements
1. **Add more Playwright tests** for other components
2. **Set up Chromatic** for visual regression testing
3. **Add performance tests** for responsive behavior
4. **Create component-specific test utilities**
5. **Add accessibility testing** with axe-core
## Key Takeaways
1. **JSDOM limitations** require separating structure tests from visibility tests
2. **Test IDs** make testing more reliable and maintainable
3. **Exported configuration** enables better data structure testing
4. **Real browser testing** is essential for responsive behavior
5. **Visual testing** catches design regressions across breakpoints
This strategy provides comprehensive coverage while respecting the limitations of different testing environments.
@@ -379,10 +379,11 @@ Visual regression tests run automatically in the CI pipeline:
## 📚 Additional Resources
- **Main Testing Documentation**: [testing-framework.md](./testing-framework.md)
- **Main Testing Documentation**: [testing-framework.md](./testing-framework.md) | [testing.md](./testing.md)
- **Playwright Visual Testing**: https://playwright.dev/docs/screenshots
- **Visual Regression Best Practices**: https://storybook.js.org/docs/writing-tests/visual-testing
- **CI/CD Integration**: [testing-quick-reference.md](./testing-quick-reference.md)
- **Performance Guide**: [performance.md](./performance.md)
---