vict00r99/rune-stone/rune-test-generator

How to Use

When given a RUNE spec (.rune file or Markdown section), generate a complete test file for the target language's testing framework.

Input: a RUNE spec + target language/framework (or auto-detect from project). Output: a complete, runnable test file.

Framework Detection

Auto-detect the testing framework from project files when possible. Common examples:

This list is not exhaustive. Any language with a testing framework is supported — adapt the output to the framework's conventions. If unclear, ask the user.

Process

Step 1: Parse the Spec

Extract from the RUNE spec:

• Function name from SIGNATURE
• Parameters and types from SIGNATURE
• Test cases from TESTS section
• Edge cases from EDGE_CASES section
• Constraints from CONSTRAINTS section (for fixture data)
• Error types from BEHAVIOR (for exception/error assertions)

Step 2: Expand [...] into Fixtures

The [...] notation in RUNE tests is shorthand for "representative data matching CONSTRAINTS." Expand it into concrete test fixtures using the target language's idioms.

From spec:

CONSTRAINTS:
  - "coupons: list of dicts with keys code, discount_type, discount_value, expires_at"
 
TESTS:
  - "validate_coupon('SAVE10', [...], '2025-01-15')[0] == True"

Python (pytest):

@pytest.fixture
def sample_coupons():
    return [
        {"code": "SAVE10", "discount_value": 10, "expires_at": "2025-12-31"},
        {"code": "OLD", "discount_value": 5, "expires_at": "2024-01-01"},  # expired
    ]

Go:

func sampleCoupons() []Coupon {
    return []Coupon{
        {Code: "SAVE10", DiscountValue: 10, ExpiresAt: "2025-12-31"},
        {Code: "OLD", DiscountValue: 5, ExpiresAt: "2024-01-01"}, // expired
    }
}

TypeScript (Jest):

const sampleCoupons = [
  { code: "SAVE10", discountValue: 10, expiresAt: "2025-12-31" },
  { code: "OLD", discountValue: 5, expiresAt: "2024-01-01" }, // expired
];

Rules for expanding [...]:

• Read CONSTRAINTS to understand the data structure
• Read EDGE_CASES to include boundary data
• Create minimal fixtures — only the data needed for the tests
• Name fixtures descriptively
• Include comments explaining why each item exists

Step 3: Generate Test Functions

Convert each pseudo-assertion into a test function using the target framework.

From spec:

TESTS:
  - "calculate_discount(100.0, 20) == 80.0"
  - "calculate_discount(-10.0, 20) raises error"

Python (pytest):

def test_discount_normal():
    assert calculate_discount(100.0, 20) == 80.0
def test_discount_negative_price_raises():
    with pytest.raises(ValueError, match="Price cannot be negative"):
        calculate_discount(-10.0, 20)

TypeScript (Jest):

test("calculates discount for normal values", () => {
  expect(calculateDiscount(100.0, 20)).toBe(80.0);
});
test("throws on negative price", () => {
  expect(() => calculateDiscount(-10.0, 20)).toThrow("Price cannot be negative");
});

Go:

func TestDiscountNormal(t *testing.T) {
    result, err := CalculateDiscount(100.0, 20)
    if err != nil { t.Fatal(err) }
    if result != 80.0 { t.Errorf("expected 80.0, got %f", result) }
}
 
func TestDiscountNegativePriceErrors(t *testing.T) {
    _, err := CalculateDiscount(-10.0, 20)
    if err == nil { t.Fatal("expected error for negative price") }
}

Rust:

#[test]
fn test_discount_normal() {
    assert_eq!(calculate_discount(100.0, 20).unwrap(), 80.0);
}
 
#[test]
fn test_discount_negative_price_errors() {
    assert!(calculate_discount(-10.0, 20).is_err());
}

Step 4: Organize Test Structure

Group tests by category using the target framework's grouping mechanism:

• pytest: comments or classes
• Jest/Vitest: describe() blocks
• Go: subtests with t.Run()
• Rust: mod tests with named functions
• JUnit: @Nested classes
• RSpec: context blocks
• ExUnit: describe blocks

Step 5: Add EDGE_CASE Tests

If the spec has EDGE_CASES, generate additional tests for each. Skip edge case tests that duplicate existing tests from the TESTS section.

Output Format

Generate a complete file with:

1. Imports — framework imports + function import
2. Fixtures — expanded [...] data
3. Test functions — grouped by category
4. File header — comment referencing the source spec

Follow the target language's naming convention for test files and functions.

Rules

• Generate ONLY test code, not the implementation
• Every test must be independently runnable
• Use the exact error messages from BEHAVIOR for exception/error matching
• Import path should match the project's module structure — ask the user if unclear
• Do not skip any test from the TESTS section
• Do not invent tests beyond what the spec defines (unless EDGE_CASES suggest them)
• Floating point comparisons: use the framework's approximate comparison (pytest.approx, closeTo, delta, etc.)
• Adapt error assertion style to the language: exceptions (Python/Java/TS), error returns (Go), Result type (Rust), pattern match (Elixir/Haskell)
• Any language with a testing framework is supported — follow its conventions