# Rohitg00 Skillkit Red Green Refactor

> Red-Green-Refactor Methodology

- Skill: `tomevault-io/rohitg00-skillkit-red-green-refactor` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/rohitg00-skillkit-red-green-refactor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/rohitg00-skillkit-red-green-refactor/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/rohitg00-skillkit-red-green-refactor

---


# Red-Green-Refactor Methodology

You are following the RED-GREEN-REFACTOR cycle for test-driven development. Every new feature, bug fix, or behavior change starts with a failing test.

## The Cycle

### 1. RED Phase — Write a Failing Test

1. **Understand the requirement** — what specific behavior must exist?
2. **Write one test** asserting that behavior
3. **Run the test** — it MUST fail (red)
4. **Verify the failure reason** — not a syntax error, but a missing implementation

The test should be focused on ONE behavior, named descriptively, and use clear assertions.

**Executable example (Jest):**
```js
// calculateTotal.test.js
const { calculateTotal } = require('./calculateTotal');

describe('calculateTotal', () => {
  it('should apply 10% discount when total exceeds 100', () => {
    const items = [{ price: 60 }, { price: 60 }]; // total = 120
    expect(calculateTotal(items)).toBe(108); // 120 * 0.90
  });
});
```
Running this now produces: `Cannot find module './calculateTotal'` — correct RED state.

---

### 2. GREEN Phase — Make the Test Pass

Write the **minimum code** needed to pass the test. Don't add anything extra.

```js
// calculateTotal.js
function calculateTotal(items) {
  const total = items.reduce((sum, item) => sum + item.price, 0);
  return total > 100 ? total * 0.9 : total;
}
module.exports = { calculateTotal };
```
Run the test — it passes. GREEN achieved. Stop here; resist adding more logic.

---

### 3. REFACTOR Phase — Improve the Code

With a passing test as your safety net, clean up the implementation. Run tests after every change.

```js
// calculateTotal.js — refactored for clarity
const DISCOUNT_THRESHOLD = 100;
const DISCOUNT_RATE = 0.9;

function calculateTotal(items) {
  const subtotal = items.reduce((sum, { price }) => sum + price, 0);
  return subtotal > DISCOUNT_THRESHOLD ? subtotal * DISCOUNT_RATE : subtotal;
}
module.exports = { calculateTotal };
```
Test still passes — GREEN maintained. Constants now communicate intent.

---

## End-to-End Example: Adding a New Behavior

**Next requirement:** apply a 15% discount when total exceeds 200.

**RED** — write the failing test first:
```js
it('should apply 15% discount when total exceeds 200', () => {
  const items = [{ price: 110 }, { price: 110 }]; // total = 220
  expect(calculateTotal(items)).toBe(187); // 220 * 0.85
});
```

**GREEN** — extend the implementation minimally:
```js
function calculateTotal(items) {
  const subtotal = items.reduce((sum, { price }) => sum + price, 0);
  if (subtotal > 200) return subtotal * 0.85;
  if (subtotal > 100) return subtotal * 0.9;
  return subtotal;
}
```

**REFACTOR** — remove duplication with a tiered structure:
```js
const DISCOUNT_TIERS = [
  { threshold: 200, rate: 0.85 },
  { threshold: 100, rate: 0.9 },
];

function calculateTotal(items) {
  const subtotal = items.reduce((sum, { price }) => sum + price, 0);
  const tier = DISCOUNT_TIERS.find(({ threshold }) => subtotal > threshold);
  return tier ? subtotal * tier.rate : subtotal;
}
```
Both tests pass — ready for the next cycle.

---

## Workflow Steps

1. **Create or open the test file first**
2. **Write ONE failing test** for the smallest testable unit
3. **Implement minimally** — just enough to pass
4. **Refactor if needed** — while tests stay green
5. **Repeat** for the next behavior

## Decision Points

### Write a new test when:
- Adding a new feature or behavior
- Fixing a bug (test the bug first, then fix it)
- Handling an edge case discovered during implementation

### Don't write a test when:
- Pure refactoring (existing tests already cover the behavior)
- Non-functional changes (formatting, comments)
- Third-party library internals

## Verification Checklist

- [ ] All new code has corresponding tests
- [ ] Tests fail when the feature is removed
- [ ] Tests pass consistently (not flaky)
- [ ] Code has been refactored for clarity
- [ ] No unnecessary code was added

## Common Mistakes to Avoid

1. **Writing tests after code** — defeats the design benefit of TDD
2. **Writing multiple tests at once** — one test drives one change
3. **Passing tests with hacks** — the test should drive good design
4. **Skipping the refactor phase** — technical debt accumulates
5. **Testing implementation details** — test behavior, not internals

## Integration with Other Skills

- **test-patterns**: Patterns for structuring tests
- **anti-patterns**: Common testing mistakes to avoid
- **debugging/root-cause-analysis**: When tests reveal unexpected failures

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/rohitg00) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-11 -->