Test the grammar, then attack the boundaries.

Jsonic++ now has three independent forms of pressure behind the same small parser: a dedicated 810-case conformance corpus, maintained sanitizer/RSS/Valgrind lifetime gates, and synchronized use inside Nift and Minify++.

Layer 1: ordinary behavior

Smoke tests cover the public shape users depend on: parse valid objects/arrays/scalars, inspect types and payloads, build documents, serialize them, and exercise the named-array streaming path. These tests answer the basic regression question: did an API behavior that used to work stop working?

Layer 2: adversarial grammar neighbors

Parser failures tend to live one character away from valid input, so the suite attacks malformed neighbors instead of relying only on representative files.

• duplicate keys and malformed object/array structure
• JSON number grammar, malformed exponents and overflow/range behavior
• significant numeric spellings that need exact-token preservation
• escape sequences and Unicode surrogate handling
• raw control characters in strings
• trailing data and invalid literal forms
• nested arrays/objects and serialization round trips
• named-array streaming and duplicate root members

Layer 3: independent conformance

The separate jsonic-cc/jsonic-conformance repository runs the pinned external corpus plus project-owned cases independently of the main parser repository. The retained result is 810/810. That campaign exposed real RFC 8259 edge cases, turned them into permanent regressions, and is now a prerequisite for benchmark or public conformance claims.

Layer 4: memory and undefined behavior

The maintained Memory & resource safety gate is complete for the retained workloads: ASan/LSan/UBSan, a long native RSS soak and independent Valgrind confirmation all pass. Passing those workloads is scoped evidence, not a timeless proof; future parser changes are expected to rerun them.

Layer 5: downstream consumers

Nift and Minify++ exercise synchronized parser copies in contexts the standalone tests do not fully reproduce. That catches integration assumptions such as error handling, configuration shapes and the exact APIs those tools depend on. Synchronization checks also make it harder for one copy to acquire an unreviewed local parser fix.

Performance is behind the correctness gate

After conformance was green, profiling and bounded hot-path optimization brought Jsonic++ into the same performance class as the conformant RapidJSON configuration on the project's same-host native JSON benchmark. The important engineering point is the order: parser speed was improved without relaxing the corpus, number-preservation behavior or malformed-input rules.

What comes next

Sustained coverage-guided fuzzing, more independent downstream users, broader toolchain/package coverage and repeated benchmark/conformance reruns are the natural next evidence layers. Exact corpus, tool and benchmark conditions should stay recorded rather than turning one successful campaign into a timeless marketing badge.

How to read “battle tested” here

It means the project turns claimed guarantees into executable pressure and retains discovered failures as regressions. It does not mean a young standalone library has magically accumulated the deployment history of projects that have existed for a decade. For that distinction, see Production readiness.