GitNexus/gitnexus/test/fixtures/rename-integration

Semantic rename integration fixtures

These projects exercise real indexing and the public rename tool in both modes (dry_run: true to preview, dry_run: false to apply). The integration test and its subprocess helper do not mock the parser, semantic resolver, registry, database, graph, filesystem, or rename functions.

Run from gitnexus/:

npm run build
npm test -- test/integration/rename-provider-matrix

Four test files partition the sorted cases evenly so CI can distribute real indexing across its existing shards. Each case runs exactly once.

Use -t 'cpp/' (for example) to select one provider. Rebuild after production changes: the helper loads the built application, including real parse workers. Do not rebuild while this suite is running. The analyzer verifies that its build does not change during indexing.

Each case contains a case.json, an independently authored before/ project, and the complete expected after/ project. Unchanged files are included too. Expected files are never generated by applying the implementation's edits.

For each case, the harness:

1. Copies the project into an isolated temporary repository and creates a real index, registry entry, and database with PDG enabled.
2. Checks indexing completeness and selects the target uniquely from persisted declarations. It asserts the specified call, access, or family edges.
3. Calls rename with dry_run: true and verifies that all source bytes are unchanged.
4. Calls rename with dry_run: false, checks the exact edit count and agreement with the preview, and compares every source file against after/.
5. Reindexes successful edits and checks the renamed declaration and the same graph relationships at their source positions.

Refusal cases assert their specific error and planning status and verify that both preview and apply preserve every source byte. They supplement successful cases; the suite requires successful fixtures for every supported language.

target and edge endpoints use name, file, optional kind, and optional zero-based startLine. Add startLine when declarations share a name. An optional expectedTargetName records an escaped graph spelling after rename, such as @Serialize; the generic harness contains no language-specific name rules.

An optional exactOutgoing: true requires every listed source/type pair to have exactly the target set specified in edges, rejecting extra overload or wrong-owner edges. This applies to cold, warm-cache, and post-rename graphs.

An optional warmParseCache: true performs a second forced index before rename, using captures cached by the cold index. It requires cache hits, zero reparsed files and no parse workers, then verifies the same persisted target identity and specified graph edges before public preview/apply. The C++ overload fixture uses this path to preserve signature-specific call edges across cache serialization.

Provider	Language behavior exercised
C	Header/definition families, function pointers, call chains, deep pointer fields
C++	Overloaded free functions across headers, virtual families, deep pointer fields, language keywords
C#	Interface/override families, public fields, escaped overloads, named arguments
COBOL	Cross-program calls, paragraph chains, nested qualified data
Dart	Interface/override and super calls, deep fields, imports, contextual identifiers
Go	Structural interfaces, exported pointer fields, package import aliases, generic type shadowing
Java	Interface/override families, overloads, deep public fields, reserved names
JavaScript	Inheritance, inferred deep fields, escaped exports, aliases and shorthand
Kotlin	Override families, typed callable references, escaped overloads, property writes
Objective-C	Protocol selectors, accessors, deep chains, ivars and same-named C symbols
PHP	Case-insensitive methods/functions, case-sensitive properties, grouped imports
Python	Override families, deep fields, aliases, Unicode names, dynamic attribute safety
Ruby	Mixins, predicate methods, chained setters, required qualified constants
Rust	Trait families, borrowed field receivers, cross-file import aliases
Swift	Protocol/override families, deep properties, escaped names and argument labels
TypeScript	Constructor-proven families/chains, aliases/shorthand, structural safety refusals
Vue	Script/template/CSS references, components, cross-file calls, opaque raw blocks
Zig	Typed container fields, import aliases and call chains

C, COBOL and Zig do not have class polymorphism matching the OO cases. Their fixtures exercise their own callable, program, or container semantics. Vue fixtures additionally cover its embedded and template name surfaces.

TypeScript's structurally typed parameters do not prove a receiver's constructor: unrelated objects can satisfy the same annotation. Open-parameter refusal cases remain unchanged, alongside successful constructor-proven cases. These fixtures are targeted regression coverage, not a claim of complete IDE refactoring parity.

C++ permits restrict as an identifier (C++ keyword table, GCC's explicit clarification). The successful type fixture exercises this spelling. The vendored tree-sitter grammar currently parses an unparenthesized int restrict(...) declarator as a C-style type qualifier, so the separate function fixture expects parse_error and unchanged sources. The parser limitation remains fail-closed.