chimera-write-the-check-before-the-code
Un criterio scritto dopo l'implementazione descrive l'implementazione. Scrivi prima il controllo che fallisce, guardalo fallire, poi costruisci.
Conferita da chi ha letto la scheda, non rivendicata dal file su se stesso. Una scheda che l'agente distilla durante un'esecuzione che ha consumato contenuti non affidabili nasce contaminata e resta in attesa di revisione prima di essere mai recuperata.
Quando viene in mente
- sto per implementare una feature
- definisco cosa vuol dire fatto
- scrivo il test dopo il codice
- il task non ha criteri di accettazione
Il valore di solito sta in Evita e Verifica. Fai è la sezione che scrivono tutti.
Il corpo della scheda qui sopra è una traduzione. L'originale inglese è ciò che la CLI importa, ciò che l'agente legge in esecuzione e ciò che l'hash qui sotto attesta.
Trigger
Stai per implementare qualcosa il cui "fatto" non è ancora osservabile — una funzionalità, la correzione di un bug, un refactor che dichiara di preservare il comportamento. Morde più forte quando l'autore e l'unico revisore sono lo stesso processo: un agente che lavora da solo, o un commit solitario che nessun altro leggerà.
Non si applica a uno spike. Un'esplorazione il cui scopo è scoprire cosa sia anche solo possibile non ha ancora un criterio di accettazione, e inventarne uno in anticipo ti ancora soltanto alla prima idea. Scrivi il controllo quando lo spike finisce e comincia il lavoro vero.
Questa card riguarda il controllo che non esiste ancora. La sua sorella,
chimera-prove-the-test-discriminates, riguarda un controllo che esiste già e potrebbe essere vuoto
— quella la usi dopo una correzione, per mostrare che il test fallisce senza di essa. Stesso
istinto, estremi opposti del lavoro.
Fai
- Prima di toccare l'implementazione, scrivi il criterio come qualcosa che può fallire: un test, un'asserzione, un comando il cui exit code si ribalta, una query con una riga attesa. La prosa non è un controllo — "l'endpoint dovrebbe essere più veloce" non lo è; "p95 sotto i 200 ms sul set di fixture, misurato dal comando di bench esistente" lo è.
- Di' da dove viene l'osservazione. Dalla macchina, non dalla tua lettura del diff.
- Esegui il controllo adesso, contro il codice non modificato. Deve fallire. Se passa, o il comportamento esiste già — nel qual caso fermati, non c'è nulla da costruire — oppure il controllo non verifica ciò che credi.
- Leggi il messaggio di fallimento. Deve fallire per il motivo previsto, non per un errore di import, una fixture mancante o un refuso nel nome del test. Un rosso che viene dalla causa sbagliata è un verde travestito.
- Fai atterrare il controllo prima dell'implementazione, in un commit a sé. Una volta che l'implementazione esiste, il controllo diventa modificabile per adattarsi a essa, e verrà modificato.
- Implementa. È fatto quando il controllo passa — non quando il codice sembra finito.
Evita
Scrivere l'asserzione dopo, a partire dall'output:
normalize(" Foo ") # -> "foo"
# test transcribed from that observation
assert normalize(" Foo ") == "foo"
Quell'asserzione non può fallire contro il codice da cui è stata copiata. Registra il comportamento
invece del requisito, quindi resta verde attraverso ogni bug su cui l'implementazione è internamente
coerente. Se il requisito era la normalizzazione NFKC e hai rilasciato strip().lower(), questo test
ti darà ragione per sempre.
Evita anche il criterio che è una riformulazione della modifica — "fatto quando la funzione è aggiunta", "fatto quando la migrazione gira". Entrambi sono soddisfatti da un corpo vuoto.
Verifica
Due domande binarie, entrambe rispondibili a partire dal repository:
- Hai visto il controllo fallire prima che l'implementazione esistesse? Se non c'è un momento in cui era rosso, non hai alcuna prova che possa diventare rosso.
- Il controllo sarebbe ancora corretto se la funzionalità fosse stata costruita in un modo completamente diverso? Un controllo che nomina dettagli interni — una chiamata privata, una riga di log, una stringa SQL esatta — è inchiodato alla tua soluzione anziché al requisito, e bloccherà il prossimo refactor senza catturare nulla.
Concretamente: git log mostra il controllo atterrare insieme all'implementazione o prima di essa, e
annullare il solo commit dell'implementazione fa diventare rossa la suite.
Rischio
Un requisito che non hai ancora capito non può essere fissato da un controllo scritto per primo. Scriverai un'asserzione precisa sulla cosa sbagliata e poi implementerai per soddisfarla — peggio che non avere alcun controllo, perché ricicla un fraintendimento dentro una suite verde di cui un revisore si fiderà. Quando il criterio è genuinamente ignoto, quello è un segnale per andare a chiedere, una domanda alla volta, non per tirare a indovinare in forma di test.
C'è anche un costo puro e semplice. Per la correzione di un refuso o una modifica alla documentazione, scrivere prima il controllo è cerimonia che nessuno paga. La card si ripaga quando il comportamento è abbastanza portante che qualcuno si fa male se "fatto" è sbagliato.
Come usarla
La scheda è un dato. Clona il repository e importala per percorso — ciò che arriva dalla rete è trattato come contaminato e trattenuto in attesa di approvazione, che è il comportamento desiderabile e il motivo per cui qui non c'è un installatore in una riga.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-write-the-check-before-the-code/SKILL.mdIntegrità
SHA-256 del file così com'è pubblicato. Chi lo importa può verificare che ciò che ha ricevuto sia ciò che questa pagina mostrava.
95d0a1b750e25af7651e85d26106a91f02f563ab1a1422edc4133d16942b67d7