PhpDocumentorRenderingContractTest
class PhpDocumentorRenderingContractTest extends TestCase (View source)
Asserts the assumptions this repository makes about phpdocumentor/type-resolver, rather than about our own output.
The stub parsers store phpDocumentor's rendering of a type verbatim, so a change in how the library stringifies types rewrites tests/cache/*.json wholesale. Without this file such a change surfaces only as a scattering of opaque string diffs in unrelated parser tests — which is exactly how the 5.6 → 6.0 bump presented: six failures that each looked like a local expectation being stale, when in fact one upstream commit had changed the rendering of every generic.
Two properties are pinned:
- Idempotency — resolving a rendered type must reproduce that rendering exactly. This is the general test for lossless rendering and the one {\StubTests\Framework\Parsers\Stubs\PhpDoc\PhpDocumentorParser::preferFaithfulType()} relies on, so a regression here silently changes which types get recovered from raw text.
- Spacing — type arguments are separated by
,. Cosmetic, but it is baked into the parsed cache, so it should change deliberately and not as a surprise.
Methods
No description
The type shapes the stub tree actually uses, one per construct.
A rendered type must survive being fed back to the resolver unchanged.
Pins the one rendering defect this repository works around, so that its fix is noticed.
No description
Type arguments are rendered ,-separated regardless of the input spacing.
Details
protected void
setUp()
No description
static array
typeShapes()
The type shapes the stub tree actually uses, one per construct.
void
testRenderingIsIdempotent(string $type)
A rendered type must survive being fed back to the resolver unchanged.
Note this pins rendering stability, not round-tripping of the input: normalisation such as
FQN-prefixing a bare identifier or rewriting T[] as array<T> legitimately changes the
string on the first pass. Only the second pass must be a no-op.
void
testCompoundArrayElementRenderingIsStillAmbiguousUpstream()
Pins the one rendering defect this repository works around, so that its fix is noticed.
Array_::__toString() appends [] to the rendered element type whenever that string already
ends in [], instead of falling through to the unambiguous array<…> branch. For a compound
element that changes the type: A|B[] parses as A|(B[]), never as (A|B)[]. type-resolver
1.x rendered these correctly via an explicit instanceof Compound branch, dropped in upstream
commit cbc0615 ("Move the logic of AbstractList::__toString() to Array_::__toString()").
{\StubTests\Framework\Parsers\Stubs\PhpDoc\PhpDocumentorParser::rendersCompoundArrayAmbiguously()} detects the shape from the resolved object graph and keeps the raw docblock text instead. When this test starts failing, upstream has fixed the rendering and that workaround — plus the corresponding cases in {\StubTests\Unit\Parsers\Stubs\PhpDoc\PhpDocumentorParserTypeRecoveryTest} — can be removed.
static array
argumentSpacing()
No description
void
testTypeArgumentsAreCommaSpaceSeparated(string $input, string $expected)
Type arguments are rendered ,-separated regardless of the input spacing.
type-resolver 1.x emitted a bare , for arrays, iterables and collections while already
using , for shapes, int ranges and int masks; 2.0 normalised everything to ,
(upstream commit 492a638, "Improve the conversion of lists to strings"), matching
phpstan/phpdoc-parser's own stringification.