Estymowanie zadań wciąż dla wielu PMów jest czymś trudnym do zrozumienia. Często estymaty są utożsamiane z czasem, jaki zostanie poświęcony na dane zadanie i często próbuje się dociekać dlaczego coś zajęło 3h, a nie 1h jak wcześniej zespół wyestymował. Niestety, błąd pojawia się już na samym początku tego rozumowania. Estymujemy ilość pracy, a nie czas jaki zajmie jej wykonanie. To jest fundamentalna różnica, trudna do zrozumienia w świecie ManDayów i DevDayów oraz traktowania deweloperów jak zasoby. Deweloper deweloperowi nie jest równy. Dwóch Seniorów też zwykle nie. Przewidywalność w projekcie jest zagadnieniem wielowymiarowym. Aby te zagadnienia zwizualizować posłużę się pewną historią.

Jakiś czas temu w mojej głowie

zrodził się pomysł dotyczący Raspberry PI i innych podobnych mini-komputerów, który polega na wystawieniu prostego interfejsu, do którego będzie można się odwoływać z dowolnego miejsca i z jego pomocą sterować np. GPIO oraz innymi zasobami takiej płytki. Jest to tak naprawdę część mojego hobbystycznego projektu, więc nie wzięło się to znikąd.

Witam w drugiej części artykułu poświęconego Codeception. Tym razem przyjrzymy się już konkretnym przykładom użycia, oraz nauczymy się jak tworzyć testy jednostkowe oraz generować raporty pokrycia testami. Nie marnując już więcej słów, przejdźmy do praktyki! Będzie dużo kodu.

Dlaczego powstał ten artykuł? Po nie tak długim poszukiwaniu nie znalazłem nigdzie jasnej instrukcji jak właściwie uruchomić codeception na yii2 w zaawansowanym szablonie. Cel jest więc prosty – pomóc w szybkiej konfiguracji środowiska do tworzenia testów na Yii2 i Codeception.