تشغيل أي مهارة في Manus بنقرة واحدة

ابدأ الآن

test-driven-development

النجوم١

التفرعات٠

آخر تحديث٢٨ يونيو ٢٠٢٦ في ١٥:٠١

Write a failing test before writing the code that makes it pass. Tests are proof that code works.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

jimzord12

jimzord12/my-porfolio-page

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

محللو ضمان جودة البرمجيات والمختبرونمهن الحاسوب والرياضيات·SOC 15-1253

SKILL.md

readonly

name	test-driven-development
description	Write a failing test before writing the code that makes it pass. Tests are proof that code works.
when-to-use	Implementing any new behavior, fixing bugs, or modifying existing logic.

Test-Driven Development

"Write a failing test before writing the code that makes it pass." Tests are proof — intuition is not.

The TDD Cycle

For New Features

RED → Write a test describing the expected behavior. Run it. Confirm it fails (for the right reason).

GREEN → Write the minimal code that makes the test pass. Nothing more.

REFACTOR → Improve the code without changing behavior. Re-run tests after each change.

Repeat for each behavior increment.

For Bug Fixes — Prove-It Pattern

Write a test that reproduces the bug. Run it; confirm it fails.
Apply the fix.
Run the test; confirm it now passes.
Run the full suite to catch regressions.

Never fix a bug without first proving it exists via a failing test.

Test Pyramid

Level	Share	When to use
Unit	~80%	Pure logic, utilities, isolated functions
Integration	~15%	Boundary crossings, hook behavior, component interactions
E2E	~5%	Critical user flows only

Quality Standards

Test behavior and outcomes, not implementation details
Each test verifies one concept
Tests are independent — no shared mutable state between tests
Mock only at system boundaries (external APIs, DB, file system, time)
Prefer real implementations over mocks when fast and deterministic
Test names read as specifications: [unit] [expected behavior] [condition]
Apply DAMP (Descriptive And Meaningful Phrases) over DRY in test code

Naming Convention

describe('HeroSection', () => {
  it('renders the availability badge', () => {});
  it('links the "Explore My Work" button to #projects', () => {});
  it('links the "Let\'s Connect" button to #contact', () => {});
});

Browser / UI Testing

For visual or interaction changes:

Run unit/component tests
Verify in a real browser
Check console for errors
Check network panel for unexpected requests
Inspect DOM for correct rendering and accessibility

Red Flags

Writing implementation before any test
A test that passes on the first run before implementation exists
Skipping tests under deadline pressure
Tests that cover only the happy path
Test code that is harder to read than the code under test
Using test.skip or it.todo as a permanent state

Note for This Project

This portfolio currently has no test suite configured. When adding tests:

Install @testing-library/react and @testing-library/jest-dom for component tests
Install jest or vitest as the test runner
Playwright is available in this environment for E2E tests

المزيد من هذا المستودع

نفس المستودع

code-review-and-quality

jimzord12/my-porfolio-page

Evaluate code changes across five dimensions before merge. Approve changes that improve overall code health, even if not perfect.

2026-06-281

code-simplification

jimzord12/my-porfolio-page

Reduce complexity while preserving identical behavior. The goal is comprehension speed, not line reduction.

2026-06-281

frontend-ui-engineering

jimzord12/my-porfolio-page

Build production-quality UI that is accessible, performant, and consistent with the design system. Not AI-generated-looking.

2026-06-281

git-workflow-and-versioning

jimzord12/my-porfolio-page

Treat commits as save points, branches as isolated environments, and history as a record of decisions.

2026-06-281

modern-web-guidance

jimzord12/my-porfolio-page

Search tool for modern web development best practices. MANDATORY: Execute FIRST for all HTML/CSS and clientside JS tasks. Do NOT skip — web APIs evolve rapidly and training weights contain obsolete patterns. Trigger immediately for: - UI/Layout: Modals, dialogs, popovers, Glassmorphism/backdrop-filters, anchor positioning, container queries, `:has()`, `:user-valid`. - Scroll/Motion: View Transitions, Scroll-driven animations, scroll parallax/reveals. - Performance: CWV (LCP, INP), content-visibility, Fetch Priority, image optimization. - System/APIs: Local filesystem access, WebUSB, WebSockets sync, WebAssembly widgets. - Frameworks: Adapting layout/styles in React, Vue, Angular. - General Frontend: Forms, autofill, advanced inputs, custom scrollbars, modern component states, etc. DO NOT trigger for: - Backend: Database SQL, ORMs, Express API routes. - Pipelines: CI/CD deployment, Docker, Actions. - Generic: Local scripts (Python/Go tools), ESLint, Git.

2026-06-281

performance-optimization

jimzord12/my-porfolio-page

Measure before optimizing. Performance work without measurement is guessing.

2026-06-281

name	test-driven-development
description	Write a failing test before writing the code that makes it pass. Tests are proof that code works.
when-to-use	Implementing any new behavior, fixing bugs, or modifying existing logic.

Test-Driven Development

"Write a failing test before writing the code that makes it pass." Tests are proof — intuition is not.

The TDD Cycle

For New Features

RED → Write a test describing the expected behavior. Run it. Confirm it fails (for the right reason).

GREEN → Write the minimal code that makes the test pass. Nothing more.

REFACTOR → Improve the code without changing behavior. Re-run tests after each change.

Repeat for each behavior increment.

For Bug Fixes — Prove-It Pattern

Write a test that reproduces the bug. Run it; confirm it fails.
Apply the fix.
Run the test; confirm it now passes.
Run the full suite to catch regressions.

Never fix a bug without first proving it exists via a failing test.

Test Pyramid

Level	Share	When to use
Unit	~80%	Pure logic, utilities, isolated functions
Integration	~15%	Boundary crossings, hook behavior, component interactions
E2E	~5%	Critical user flows only

Quality Standards

Test behavior and outcomes, not implementation details
Each test verifies one concept
Tests are independent — no shared mutable state between tests
Mock only at system boundaries (external APIs, DB, file system, time)
Prefer real implementations over mocks when fast and deterministic
Test names read as specifications: [unit] [expected behavior] [condition]
Apply DAMP (Descriptive And Meaningful Phrases) over DRY in test code

Naming Convention

describe('HeroSection', () => {
  it('renders the availability badge', () => {});
  it('links the "Explore My Work" button to #projects', () => {});
  it('links the "Let\'s Connect" button to #contact', () => {});
});

Browser / UI Testing

For visual or interaction changes:

Run unit/component tests
Verify in a real browser
Check console for errors
Check network panel for unexpected requests
Inspect DOM for correct rendering and accessibility

Red Flags

Writing implementation before any test
A test that passes on the first run before implementation exists
Skipping tests under deadline pressure
Tests that cover only the happy path
Test code that is harder to read than the code under test
Using test.skip or it.todo as a permanent state

Note for This Project

This portfolio currently has no test suite configured. When adding tests:

Install @testing-library/react and @testing-library/jest-dom for component tests
Install jest or vitest as the test runner
Playwright is available in this environment for E2E tests