feat: Create TestRunner.TestCase with shared test definitions (#200)

[andreasronge]

Summary

Extracts test case definitions from JSON and Lisp test runners into a centralized TestRunner.TestCase module. This eliminates duplication and provides a single source of truth for test specifications across both DSLs.

Implements task 1.3 from Epic #195 (Unify Demo Test Runners).

Changes

• New module: demo/lib/ptc_demo/test_runner/test_case.ex
  • common_test_cases/0: 9 test cases for both DSLs (counts, filters, aggregations)
  • lisp_specific_cases/0: 10 test cases unique to Lisp (sort operations, cross-dataset queries)
  • multi_turn_cases/0: 2 test cases requiring memory persistence

Test Plan

• Module compiles without warnings
• All functions are callable from IEx
• Test case counts verified:
  • Common: 9 cases
  • Lisp-specific: 10 cases
  • Multi-turn: 2 cases
• No regression in existing tests (1081 tests pass)
• Code formatted with mix format
• Pre-commit checks pass (formatting, compilation, Credo)

Fixes #200

🤖 Generated with Claude Code

[github-actions]

PR Review: Create TestRunner.TestCase with shared test definitions

Summary

This PR creates the PtcDemo.TestRunner.TestCase module with centralized test case definitions. The implementation correctly follows the issue specification (#200) and the test-runner-refactor-plan.md spec document, with proper organization into common, Lisp-specific, and multi-turn categories.

What's Good

• Matches spec exactly: The module structure with common_test_cases/0, lisp_specific_cases/0, and multi_turn_cases/0 follows the spec document
• Correct test categorization: Test cases match the explicit list in issue Create TestRunner.TestCase with shared test definitions #200:
  • 9 common cases that work for both DSLs
  • 10 Lisp-specific cases (sort operations, expense queries, cross-dataset)
  • 2 multi-turn cases requiring memory persistence
• Good documentation: Clear @moduledoc, @doc annotations with return type documentation, and @spec for all functions
• Follows existing patterns: Module structure matches TestRunner.Base and TestRunner.Report conventions
• Clean code: Well-organized with logical groupings (simple counts, filtered counts, aggregations, etc.)

Issues (Must Fix)

None identified.

Suggestions (Optional)

1. Future work - JSON-specific cases: The original test_runner.ex has 2 tests not included here (credit card payment queries). For future reference, if JSON multi-turn support is added, consider whether these should be:

   • Added to common_test_cases/0 if Lisp can handle them
   • Added as a new json_specific_cases/0 function for parity

   This is out of scope for this PR since the issue explicitly lists 9 common tests and doesn't include credit card tests.

Security

No concerns - this is pure data definition with no external I/O or user input handling.

Documentation

The module has comprehensive documentation:

• @moduledoc explains the module's purpose
• Each function has @doc with:
  • Description of what it returns
  • Key structure documentation (:query, :expect, :constraint, :description)
  • Note about :queries key for multi-turn tests
• @spec annotations for all public functions

Verdict

Approve - The implementation correctly follows the issue specification and spec document. Test case counts and categorizations are accurate. Code quality is good with proper documentation and typing.

[andreasronge]

Auto-Triage Summary

Review Analysis

The PR review provided an Approve verdict with no required fixes. One suggestion was noted as future work but is correctly marked as out-of-scope for this PR.

Decisions Made

#	Issue	Decision	Reasoning
1	JSON-specific test cases (credit card queries)	IGNORE	Review correctly identifies this as out-of-scope. The PR follows issue #200 specification which explicitly lists 9 common tests. The 2 credit card payment query tests exist only in the JSON runner (not in Lisp runner), so they are JSON-specific, not common tests. Adding them would be inconsistent with the spec. This can be considered later if JSON multi-turn support is added.

Status

• FIX_NOW items: 0
• Issues created: 0
• Items ignored: 1 (out-of-scope future work, correctly identified in review)

Next Steps

Adding ready-to-merge label since there are no required fixes.