chimera-write-the-check-before-the-code
Kryterium napisane po implementacji opisuje implementację. Napisz najpierw zawodzące sprawdzenie, zobacz, jak zawodzi, i dopiero buduj.
Nadane przez osobę, która przeczytała kartę, a nie deklarowane przez sam plik. Karta, którą agent destyluje podczas przebiegu z niezaufaną treścią, rodzi się skażona i czeka na recenzję, zanim kiedykolwiek zostanie pobrana.
Kiedy przychodzi na myśl
- przed implementacją funkcji
- definiowanie, co znaczy gotowe
- pisanie testu po kodzie
- zadanie bez kryteriów akceptacji
Wartość zwykle kryje się w Unikaj i Sprawdź. Rób to sekcja, którą pisze każdy.
Treść karty powyżej to tłumaczenie. Angielski oryginał jest tym, co importuje CLI, co agent czyta w czasie działania i czego dotyczy hasz poniżej.
Wyzwalacz
Masz zamiar zaimplementować coś, czego "gotowe" nie jest jeszcze obserwowalne — funkcję, poprawkę błędu, refaktor twierdzący, że zachowuje zachowanie. Gryzie najmocniej, gdy autorem i jedynym recenzentem jest ten sam proces: agent pracujący sam albo samotny commit, którego nikt inny nie przeczyta.
Nie dotyczy to spike'u. Eksploracja, której celem jest dowiedzieć się, co w ogóle jest możliwe, nie ma jeszcze kryterium akceptacji, a wymyślanie go z góry tylko zakotwicza cię przy pierwszym pomyśle. Napisz sprawdzenie, gdy spike się kończy, a zaczyna prawdziwa praca.
Ta karta dotyczy sprawdzenia, które jeszcze nie istnieje. Jej siostra,
chimera-prove-the-test-discriminates, dotyczy sprawdzenia, które już istnieje i może być puste —
po tamtą sięgasz po poprawce, żeby pokazać, że test bez niej zawodzi. Ten sam instynkt, przeciwne
końce pracy.
Rób
- Zanim dotkniesz implementacji, zapisz kryterium jako coś, co może zawieść: test, asercję, polecenie, którego kod wyjścia się odwraca, zapytanie z oczekiwanym wierszem. Proza nie jest sprawdzeniem — "endpoint powinien być szybszy" nim nie jest; "p95 poniżej 200 ms na zestawie fixture'ów, mierzone istniejącym poleceniem bencha" jest.
- Powiedz, skąd bierze się obserwacja. Z maszyny, nie z twojego odczytania diffa.
- Uruchom sprawdzenie teraz, wobec niezmodyfikowanego kodu. Musi zawieść. Jeśli przechodzi, albo zachowanie już istnieje — i wtedy przestań, nie ma czego budować — albo sprawdzenie nie testuje tego, o czym myślisz.
- Przeczytaj komunikat porażki. Musi zawieść z zamierzonego powodu, nie na błędzie importu, brakującym fixturze czy literówce w nazwie testu. Czerwień z niewłaściwej przyczyny jest zielenią w przebraniu.
- Wprowadź sprawdzenie przed implementacją, we własnym commicie. Gdy implementacja już istnieje, sprawdzenie staje się edytowalne pod nią — i zostanie wyedytowane.
- Implementuj. Gotowe jest wtedy, gdy sprawdzenie przechodzi — nie gdy kod wygląda na skończony.
Unikaj
Pisanie asercji po fakcie, z wyjścia:
normalize(" Foo ") # -> "foo"
# test transcribed from that observation
assert normalize(" Foo ") == "foo"
Ta asercja nie może zawieść wobec kodu, z którego została skopiowana. Zapisuje zachowanie zamiast
wymagania, więc pozostaje zielona przez każdy błąd, co do którego implementacja jest wewnętrznie
spójna. Jeśli wymaganiem była normalizacja NFKC, a wypuściłeś strip().lower(), ten test będzie się
z tobą zgadzał na zawsze.
Unikaj też kryterium, które jest przeformułowaniem zmiany — "gotowe, gdy funkcja jest dodana", "gotowe, gdy migracja się wykonuje". Oba spełnia puste ciało.
Sprawdź
Dwa pytania zero-jedynkowe, na oba odpowiada repozytorium:
- Czy widziałeś, jak sprawdzenie zawodzi, zanim implementacja istniała? Jeśli nie ma momentu, w którym było czerwone, nie masz dowodu, że może się czerwone zrobić.
- Czy sprawdzenie byłoby wciąż poprawne, gdyby funkcję zbudowano zupełnie inaczej? Sprawdzenie nazywające wnętrzności — prywatne wywołanie, linię logu, dokładny ciąg SQL — jest przypięte do twojego rozwiązania, a nie do wymagania, i będzie blokować następny refaktor, nie wyłapując niczego.
Konkretnie: git log pokazuje sprawdzenie wprowadzone przed implementacją albo razem z nią, a
cofnięcie samego commita implementacji czyni zestaw czerwonym.
Ryzyko
Wymagania, którego jeszcze nie rozumiesz, nie da się przypiąć sprawdzeniem napisanym najpierw. Napiszesz precyzyjną asercję o niewłaściwej rzeczy, a potem zaimplementujesz pod nią — gorzej niż brak sprawdzenia, bo pierze nieporozumienie na zielony zestaw, któremu recenzent zaufa. Gdy kryterium jest naprawdę nieznane, to sygnał, żeby iść zapytać, po jednym pytaniu naraz, a nie zgadywać w formie testu.
Jest też zwykły koszt. Przy poprawce literówki albo edycji dokumentacji pisanie sprawdzenia najpierw to ceremonia, za którą nikt nie płaci. Karta zarabia na siebie, gdy zachowanie jest na tyle nośne, że ktoś ucierpi, jeśli "gotowe" okaże się nieprawdą.
Jak użyć
Karta to dane. Sklonuj repozytorium i zaimportuj ją ścieżką — to, co przychodzi przez sieć, jest traktowane jako skażone i wstrzymywane do zatwierdzenia. Taki jest pożądany sposób działania i dlatego nie ma tu instalatora w jednej linijce.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-write-the-check-before-the-code/SKILL.mdIntegralność
SHA-256 pliku w postaci opublikowanej. Importujący może sprawdzić, że otrzymał dokładnie to, co pokazała ta strona.
95d0a1b750e25af7651e85d26106a91f02f563ab1a1422edc4133d16942b67d7