Test Strategy and C Test Suite Parity

Status

Accepted

Context

The C Oniguruma test suite consists of 8 test files covering different encodings, features, and API surfaces. The question is which tests to port and how to structure them in Rust.

Decision

Ported Test Suites (5)

All C test files that exercise the engine with ASCII/UTF-8 are ported 1:1:

Total: 1,882 #[test] functions (1,695 from the C test suite + 187 Rust-specific tests for edge cases, error paths, and Scanner API).

Not Ported (3)

Naming Convention

All ported test files use the compat_ prefix to indicate they are direct translations of C test cases. Each Rust #[test] function corresponds to one x2()/x3()/n()/e() call in the C original:

• x2(pattern, string, from, to) -- match expected at [from, to)
• x3(pattern, string, from, to, mem) -- match in capture group mem
• n(pattern, string) -- no match expected
• e(pattern, string) -- compile or match error expected

The conditional_recursion_complex Test

One test is marked #[ignore] and must never be run in the full suite:

#[test]
#[ignore]
fn conditional_recursion_complex() { ... }

This test exercises deeply nested conditional recursion that causes the VM to run indefinitely (same behavior as the C original). It exists to document the pattern, not to be executed routinely.

Consequences

• Running cargo test -- --ignored on the full suite will hang. This is documented in CLAUDE.md and the README.
• Debug builds require increased stack size for the full suite (see ADR-013).
• Recommended test commands:

  RUST_MIN_STACK=268435456 cargo test --test compat_utf8 -- --test-threads=1
  cargo test --test compat_syntax
  cargo test --test compat_options
  cargo test --test compat_regset
  RUST_MIN_STACK=268435456 cargo test --test compat_back -- --test-threads=1

  Copy