[aczutuse]

Jaka biblioteka jest se najlepsza do testowania w #kotlin ?
#spock jest se najlepszy w #java ale tak średnio działa z #kotlin Nie widzi np. companion object i defaultowych wartości w konstruktorze.
#programowanie

[Kresse]

@aczutuse: kotest z mockk są spoczko

[KwasowyProktolog10kJava]

@aczutuse: Proponuję czystego Junit5, dużo interface'ów - stub'y i fake implementacje - mockowanie jest dla ciot.

[iamtehwin]

@aczutuse unit test - junit5, mockk i turbine - stack w nowych projektach

[nad__czlowiek]

dużo interface'ów - stub'y i fake implementacje

@KwasowyProktolog10kJava: i potem #!$%@? się 6h przy 3-godzinnym tasku nad fejk implementacją do unit testów, które sprawdzają tylko jedną klaskę.

Unity niech #!$%@?ą mocki ile wlezie bo czas to pieniądz, ale po prostu lepiej zrobić dużo testów integracyjnych, które postawią jakąś bazkę embedded czy test-container.

Największy problem z fejk implementacjami do testów jest taki, że pracujemy w Scrumie, Agile. Wymagania biznesowe zmieniają się co

[aczutuse]

@nad__czlowiek: moim zdaniem rozwiązaniem na to jest BDD. Niech w opisach tasków w jirze będą zdefiniowane scenariusze. Staje się to od razu dokumentacją i przepisujesz to na scenariusz testowy. Następnie do scenariuszu dopisujesz kod.

Taki scenariusz ma mieć wartość biznesową w stylu "when user adds product to basket then total value of the basket is upgraded". I ma to być test end to end. Wchodzi coś do endpointa i coś wychodzi

[aczutuse]

@iamtehwin: unit5 byłby spoko, gdyby nie ciemiężne parametrized tests. Spock ma to zrobione leciutko.

[nad__czlowiek]

@aczutuse: no ale to widzisz, w takim przypadku lepiej postawić jakieś in-memory H2 które będzie udawać produkcyjnego Postgresa i postawić kontekst springa, wołamy endpoint i sprawdzamy stan bazy.

To wyjdzie z tego integracja a nie unit test

[aczutuse]

@nad__czlowiek: unit to najmniejsza jednostka testowana, dla mnie liczy się najmniejsza jednostka biznesowa. Testujesz logikę a nie kod.

[Saly]

@nad__czlowiek: unit to pojęcie względne. Purysta mógł by powiedzieć, że twój test nie jest unit testem, bo zależy od standardowej klasy String a nie jakiejś abstrakcji.

Najlepiej mieć to w p*****e i pisać testy bez myślenia o tym podziale

[aczutuse]

@Saly: trzeba pisać tak jak zespół ustali :)

[tylko_zerknalem]

i potem #!$%@? się 6h przy 3-godzinnym tasku nad fejk implementacją do unit testów, które sprawdzają tylko jedną klaskę.

@nad__czlowiek: pisanie fejków nigdy nie trwa 6h, plus jak już raz się go napisze to reużywasz go przy innych zadaniach. Długoterminowo sprawdzają się dużo lepiej niż mockowanie. Plus można ich używać poza testem, np. w trakcie lokalnego developmentu jeżeli nie chcesz uderzać do rzeczywistego systemu zewnętrznego.

Unity niech #!$%@?ą mocki ile wlezie