Gate: mock-typed

The test double derives from the real module (not a frozen copy of the contract).

Property	Value
Checker	mock-typed
Confronts	test
Blocking by default — new project	yes
Blocking by default — existing project	no — informs
Presupposes	derived.mock_contract — until these are declared in anchors.yaml, the gate is pending and asks nothing

How it measures

Confronts a test against the hole that is the most treacherous of the whole gate family, because it is not the absence of proof — it is FALSE proof. A test that doubles its neighbour keeps passing after the neighbour changes signature, return or name: the double became a frozen copy of a contract that no longer exists. The green certifies the old version, and nobody goes looking for a defect where there is a green test.

The neighbouring gates do not reach it, and each of them answers “yes” about a test that lies:

gate	what it asks	its answer
unit-complete	does the test EXIST?	it does
feature-test-match	does the scenario match a test case?	it does
tests-green	did the run pass?	it did

The defence is not the gate reimplementing type checking: it is demanding that the double be TIED to the original by a mechanism the language already knows how to check. In TypeScript, annotating the factory with a partial of the real module’s type makes the compiler accuse both a non-existent method and a divergent return; in Python it is autospec; in Go it is the interface. The framework does not know which — the project declares it in derived.mock_contract, and this gate charges the presence of the tie.

What separates it from mock-stamped: this one solves the problem where the LANGUAGE helps, and only there. mock-stamped is the agnostic half, which hashes text and works where there is no structural type to lean on.

Declaring it

gates:
  - name: mock-typed
    on: [test]
    check: mock-typed

Source: checker · its spec