UnitTests

Łamanie enkapsulacji w klasach testowanych

Posted on Updated on

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

Posted on

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ć.

AutoFixture scenariusze

Posted on Updated on

var twoUsers = fixture.CreateMany<User>(2);