Battle tested

Test the grammar, then attack the boundaries.

Jsonic++ begins with unusual inherited evidence: the same parser implementation was already exercised inside Nift's configuration, tracking, project-contract, schema and parser workflows, and inside Minify++'s JSON handling. Standalone ownership lets that evidence become parser-specific rather than incidental.

Current status: extracted and independently testable.The standalone repository keeps dedicated smoke/adversarial coverage and sanitizer targets, while synchronized Nift and Minify++ copies provide downstream integration pressure. External conformance and fuzz campaigns remain an important next layer rather than a box we pretend is permanently checked.

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 rejection
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: memory and undefined behavior

The maintained Memory & resource safety page separates the upcoming dedicated leak/soak campaign from this broader test overview and will be refreshed as those gates are rerun.

The repository includes AddressSanitizer/UndefinedBehaviorSanitizer validation with leak detection in the test workflow. Sanitizers are especially valuable for malformed-input work because many parser bugs only become dangerous when an unusual escape, truncation or nesting pattern drives an unexpected branch.

Passing sanitizer workloads is evidence for those workloads—not a timeless proof that arbitrary future code cannot contain a lifetime or bounds bug. The useful property is repeatability: parser changes can be pushed through the same instrumentation again.

Layer 4: 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.

What the suite is trying to prevent

False acceptanceMalformed JSON quietly accepted as if it were valid, especially duplicate keys, invalid escapes and malformed numbers.

Behavior driftSerializer/parser disagreement, changed error behavior, or different semantics between standalone and vendored copies.

What comes next

JSONTestSuite-style conformance corpora, sustained coverage-guided fuzzing, sanitizer repetition and differential testing against mature implementations are natural next evidence layers. Those runs should preserve exact corpus/tool versions and minimized failures rather than being converted into vague “millions of tests” marketing.

How to read “battle tested” here

It means the project tries to turn each claimed guarantee into executable pressure and to retain bugs 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.