Test-Driven Development for JSON Formatter Features

Red: Write the failing test

describe('JSON Formatter - Basic Indentation', () => {
  it('should format a simple flat object with 2-space indentation', () => {
    const input = '{"name":"Alice","age":30}';
    const expectedOutput = `{
  "name": "Alice",
  "age": 30
}`;
    expect(formatJson(input, 2)).toBe(expectedOutput);
  });
});

Running this test now will fail, as `formatJson` likely doesn't exist or doesn't produce the expected output yet.

Green: Write just enough code

Implement a basic parser and formatter that can handle a simple flat object, focusing *only* on making the above test pass. Don't worry about nested structures, arrays, or other types yet. Your initial `formatJson` might be very crude.

// In formatter.ts
function formatJson(jsonString: string, indentSpaces: number): string {
  // A very basic implementation just to pass the first test
  // This needs a proper parser ideally, but for GREEN phase,
  // a simple string manipulation might suffice temporarily IF it passes the test.
  // A real implementation would parse first. Let's assume a basic parse function exists.
  try {
    const obj = JSON.parse(jsonString); // Use built-in parser for simplicity in example
    return JSON.stringify(obj, null, indentSpaces); // Built-in stringify with indentation
  } catch (e) {
    throw new Error("Invalid JSON input");
  }
}

// This function is now enough to make the specific test above pass.
// (Note: Using built-in JSON.parse/stringify is cheating for building a *custom* formatter,
// but illustrates the GREEN step conceptually - write *anything* that makes the test pass).
// A true custom formatter would replace JSON.parse/stringify with its own logic.

Run the test again. It should now pass.

Refactor: Improve the code

The current implementation uses `JSON.parse` and `JSON.stringify`, which isn't what you'd do if building a formatter from scratch. In a real scenario, the refactor phase might involve:

• Structuring the formatter logic (e.g., using a tokenizer and a recursive formatter function).
• Improving variable names or code clarity.
• Preparing the code structure for handling more complex cases easily.

After refactoring, run the test again to ensure you haven't broken anything.

Red: New failing test

describe('JSON Formatter - Nested Structures', () => {
  it('should format a nested object correctly', () => {
    const input = '{"user":{"name":"Bob","address":{"city":"London"}}}';
    const expectedOutput = `{
  "user": {
    "name": "Bob",
    "address": {
      "city": "London"
    }
  }
}`;
    expect(formatJson(input, 2)).toBe(expectedOutput);
  });
});

This new test will fail if your formatter only handled flat structures.

Green: Implement nesting logic

Modify your `formatJson` (or the underlying formatting functions) to recursively handle nested objects, increasing the indentation level for each nested level. Write *just enough* code to make this specific test pass.

// Inside formatJson or a helper formatter function...
// You'd add logic to detect nested objects/arrays and call
// the formatting logic recursively with an increased indent level.
// e.g., a function like formatValue(value, currentIndentLevel)

Run *all* tests. The new nested test should pass, and the previous flat object test must still pass.

Refactor: Clean up nesting code

Refine the recursive formatting logic. Ensure indentation is calculated correctly. Make sure it handles commas properly for the last element in a nested object. Run all tests again.

Red: Add array and type tests

describe('JSON Formatter - Arrays and Types', () => {
  it('should format a simple array', () => {
    const input = '[1,"two",true,null]';
    const expectedOutput = `[
  1,
  "two",
  true,
  null
]`;
    expect(formatJson(input, 2)).toBe(expectedOutput);
  });

  it('should format an object containing an array', () => {
    const input = '{"list":[1,2,{"item":3}]}';
    const expectedOutput = `{
  "list": [
    1,
    2,
    {
      "item": 3
    }
  ]
}`;
    expect(formatJson(input, 2)).toBe(expectedOutput);
  });

  it('should handle different data types correctly', () => {
    const input = '{"num":123.45,"bool":false,"nil":null,"str":"hello"}';
    const expectedOutput = `{
  "num": 123.45,
  "bool": false,
  "nil": null,
  "str": "hello"
}`;
    expect(formatJson(input, 2)).toBe(expectedOutput);
  });
});

These new tests will fail.

Green: Implement array and type handling

Update your formatter to recognize arrays (`[]`), iterate through their elements, handle commas, and apply correct indentation. Ensure it can distinguish and format numbers, booleans, and null correctly (they don't need quotes like strings).

Run all tests. They should all pass now.

Refactor: Refine array and type logic

Review the array formatting code. Is the comma logic clean? Is the type detection robust? Can the value formatting be improved? Run all tests to confirm.

Red: Test for invalid input

describe('JSON Formatter - Error Handling', () => {
  it('should throw an error for invalid JSON', () => {
    const input = '{"name":"Alice", age:30}'; // Missing quotes around 'age'
    expect(() => formatJson(input, 2)).toThrow('Invalid JSON input'); // Or a more specific error message
  });

  it('should throw an error for non-JSON string', () => {
    const input = 'just plain text';
    expect(() => formatJson(input, 2)).toThrow('Invalid JSON input');
  });
});

These tests should fail if your formatter doesn't have input validation, or if it crashes instead of throwing a controlled error.

Green: Add validation

Add validation at the beginning of your `formatJson` function. A simple approach is to use a `try...catch` block around the parsing step.

function formatJson(jsonString: string, indentSpaces: number): string {
  try {
    // Attempt to parse the string first
    const parsed = JSON.parse(jsonString); // Or use your custom parser
    // If parsing succeeds, proceed to format the parsed object/array
    return myCustomFormatLogic(parsed, indentSpaces);
  } catch (e) {
    // If parsing fails, throw a user-friendly error
    throw new Error("Invalid JSON input");
  }
}

Run all tests. The new error tests should pass, and existing tests should still pass (as valid JSON is handled).

Refactor: Improve error reporting

Can you make the error message more specific? Include the line or column number where the parsing failed? This would require integrating error reporting into your custom parser (if not using `JSON.parse`). Run tests again.