name: dev-test description: "Structured development and testing SOP for implementing code changes. Covers codebase study, minimal focused implementation, test writing patterns, test execution, and diff review. Applies to any development work — bug fixes, features, refactors, or open-source contributions. Use when you need a disciplined development workflow with built-in quality checks."

Dev Test — Development & Testing SOP

Overview

A structured workflow for implementing code changes with quality built in. Covers the full cycle from understanding the codebase to having a verified, reviewable diff.

Use cases: Bug fixes, feature development, refactoring, open-source contributions, any code change that needs to be correct and maintainable.

Workflow

Phase 1: Study Before Coding

Never write code before understanding the context. This phase prevents wasted effort and bad designs.

1a. Understand the project conventions

Check for and read these files (if they exist): - CONTRIBUTING.md — contribution guidelines - .editorconfig — formatting rules - pyproject.toml / package.json / Makefile — project config, linting, formatting - tox.ini / .flake8 / .eslintrc — code style rules

1b. Study the area of change

• Read the module(s) you'll be modifying
• Trace the execution path around the bug/feature
• Understand data flow: what goes in, what comes out
• Note dependencies: what other modules interact with this code

1c. Study existing tests

• Find the test directory structure: tests/, __tests__/, test/
• Note the test framework: pytest, jest, go test, JUnit, etc.
• Study naming conventions: test_feature.py, feature.test.ts, feature_test.go
• Note fixture/setup patterns used
• Check for test utilities, factories, or mocks

1d. Draft a mental model

Before writing code, articulate: - What needs to change (specific behavior) - Where in the code (files, functions, classes) - How you'll change it (approach) - What could go wrong (edge cases, regressions)

Phase 2: Implement

Core principles

1. Minimal, focused changes
2. Fix the bug / add the feature. Nothing else.
3. Avoid unrelated formatting changes, import reordering, or drive-by refactors.

4. If you spot something else to fix, note it for a separate commit/PR.

5. Follow existing patterns

6. Match the codebase's style, not your preferred style
7. Use the same naming conventions, indentation, comment style

8. If the project uses snake_case, don't introduce camelCase

9. Add comments for non-obvious logic

10. "Why" comments, not "what" comments

11. Explain trade-offs, workarounds, and intentional decisions

12. Design for quality

Phase 3: Write Tests

Test categories (implement in order)

1. Fix verification — prove the bug is fixed / feature works test_feature_handles_null_input() # The exact scenario from the issue

2. Edge cases — boundary conditions test_feature_with_empty_string() test_feature_with_max_length_input() test_feature_with_special_characters()

3. Error handling — invalid inputs, failure paths test_feature_raises_on_invalid_type() test_feature_returns_none_on_missing_key()

4. Regression — existing behavior preserved test_existing_behavior_unchanged() test_other_module_still_works()

Test writing guidelines

• One assertion per test (ideally) — makes failures easy to diagnose
• Descriptive names — test_oauth_token_refreshes_when_expired not test_token

• Arrange-Act-Assert pattern: ```python def test_feature(): # Arrange input_data = create_test_data()

  # Act result = feature(input_data)

  # Assert assert result.status == "success" ``` - Use fixtures for reusable setup - Mock external dependencies — network calls, file system, databases - Test behavior, not implementation — don't assert on internal state

Phase 4: Run Tests

Progressive testing strategy

# 1. Run only your new/modified tests first (fast feedback)
python -m pytest tests/test_my_feature.py -v --tb=short
# or: npm test -- --testPathPattern=my_feature
# or: go test ./pkg/my_feature/... -v

# 2. Run the full test module/directory
python -m pytest tests/ -v --tb=short

# 3. Run the entire test suite (before committing)
python -m pytest --tb=short
# or: npm test
# or: go test ./...

Handling test results

Phase 5: Review the Diff

Before committing, review every line of your diff.

# Overview of what changed
git diff --stat

# Full diff
git diff

# If already staged
git diff --cached

Diff review checklist

• [ ] Every change is intentional (no accidental edits)
• [ ] No debug prints, TODO comments, or temporary code left in
• [ ] No secrets, tokens, or personal paths hardcoded
• [ ] No unrelated formatting changes

  來源於7w4.net。

• [ ] All new functions/classes have appropriate docstrings/comments
• [ ] Test coverage looks adequate for the changes
• [ ] File additions are in the right directories

Phase 6: Commit

# Stage specific files (never use `git add .`)
git add path/to/modified_file.py
git add tests/test_new_feature.py

# Verify staged files
git diff --cached --stat

# Commit with conventional message
git commit -m "fix(module): short description of what was fixed

Longer explanation of why, if non-obvious.

Addresses #issue_number"

Commit message format

{type}({scope}): {concise description}

{body: what and why, not how}

{footer: issue refs, test results, breaking changes}

Output

• Committed code changes + tests on feature branch
• All tests passing
• Clean, reviewable diff

Tips

• This skill works standalone for any development task.
• In a contribution pipeline, it follows repo-setup and feeds into pr-pilot.
• For large features, repeat Phase 2-5 in small increments rather than one big change.
• When pair-programming with AI: have the AI study the codebase (Phase 1) before asking it to implement anything.

這個 Skill 質量不錯，內容專業且實用。它把開發測試工作拆成清晰的步驟，從學習程式碼到寫測試再到提交都有覆蓋。表格和程式碼示例讓內容易讀，操作清單也很實用。不足是缺少快速入門的示例和常見問題解答，新手可能需要花時間理解每個階段的具體做法。總體適合需要規範開發流程的團隊使用。