UnitTests
Łamanie enkapsulacji w klasach testowanych
Oglądałem jeden z odcinków o testach by Seemann na Pluralsight.
Autor nie widział nic złego w udostępnianiu publicznie wstrzykiwanych zależności lub danych. Ułatwia to testowanie, lecz niestety łamie zasadę enkapsulacji. Nie jest to jednak złe ponieważ gdy korzystamy z interfejsow (a nie wyobrażam sobie żeby było inaczej) to w kodzie produkcyjnym nie będziemy mieli do tego dostępu. Oczywiście nie robimy hacków z castowanie itp. Wtedy takie udostępnione dane mogą być dotykane tylko w testach i może dzięki temu kod będzie prostszy.
Update:
Chociaż jak to tak teraz czytam to przypomina mi się inny talk który mówi o tym że to jednak zły design bo cokolwiek pokazujemy na zewnątrz może kiedyś wypłynąć.
xUnit – zalety Setup w konstruktorze
Zaleta xUnit versus NUnit jest to że kod inicjalizujący każdy pojedynczy test jest w konstruktorze zamiast w metodzie Setup() otagowanej atrybutem Setup. Analogicznie sprzątanie po teście jest w metodzie Dispose() zamiast w TearDown.
Zauważyłem dziś dodatkowy plus. Dzieki temu większość pól które inicjalizujemy na początku testu może być oznaczona jako readonly. Bardzo się przydaje bo mamy pewność po co są te pola i nikt nie spróbuje ich ruszyć.
