Wpis z mikrobloga

@placebo_: fajna sprawa, ale bardzo ciężka do implementacji. Głównie przez to jak długo testy potrafią trwać (bo np. czekamy na kontenery) co utrudnia mocno takie podejście, gdzie liczba iteracji kod -> test jest ogromna
@MacDada: definicja unit testów jest tak śliska, że nie chcę znowu podności dyskusji która nie ma sensu. Tak czy owak niezależnie od typu zależności (rzeczywista baza w kontenerze vs jakaś imitiacja oparta o hash mapy vs mocki) cała procedura red/green/refactor wygląda identycznie

Ale tu piszesz o jakimś CI/CD czy o czym?


@Hopsiup-siup: lokalne uruchomienie. TDD wymusza ogromną liczbę iteracji i bez szybkich testów produktywność mocno spada. CI/CD oczywiście też jest
TDD wymusza ogromną liczbę iteracji i bez szybkich testów produktywność mocno spada


@Saly: Dokładnie. Co się wtedy dzieje?

a.) testy mnie spowalniają -> odpuszczam testy (buuuuuu)
b.) chcę pisać szybkie testy -> muszę więc robić więcej małych testów -> żeby robić małe testy, testowany kod musi być również mniejszy łatwy do izolowania -> piszę więc kod bardziej wyspecjalizowany, odseparowany -> TDD wymusza pisanie lepszej jakości kodu.

Separation of concerns. SOLID. Dziel
W programowaniu. 20% funkcjonalnych, 80% jednostkowych.


@MacDada: idiotyzm. Każdy projekt jest inny i jakiekolwiek liczby są z czapy. Inaczej będą wyglądały testy np. jakiegoś kompiliatora (czyli generalnie projektów, gdzie kod jest mocno deterministyczny i testowanie f(input) -> output pokrywa praktycznie wszystko co trzeba pokryć) a inaczej typowego serwsiu walącego do bazy. Jak w kodzie masz przykładowo 5% logiki a 95% jest w zapytaniach do bazy to co ci dadzą takie testy?
Każdy projekt jest inny i jakiekolwiek liczby są z czapy.


@Saly: https://pl.wikipedia.org/wiki/Zasada_Pareta

Nie chodzi o 20, 19 czy 21 procent, ale o ogólny rozkład w praktyce –> z przeważającą liczbą małych testów, „jednostkowych”.

Jak w kodzie masz przykładowo 5% logiki a 95% jest w zapytaniach do bazy to co ci dadzą takie testy?


Preferuję podejście code first m.in. z tego powodu. Łatwiej jest testować logikę w kodzie niż w bazie. Łatwiej
Preferuję podejście code first m.in. z tego powodu. Łatwiej jest testować logikę w kodzie niż w bazie. Łatwiej jest też wprowadzać zmiany (maintenance).


@MacDada: z mojej perspektywy to bardziej wygląda jak utrwalenie się w decyzji, którą podjąłeś. Jeśli za aksjomat przyjmiesz, że unitów ma być dużo więcej niż integracyjnych to racja. Jak nie to ja nie widzę problemu. Testując np. API nie ma dla mnie różnicy, czy pod spodem jest baza
Testując np. API nie ma dla mnie różnicy, czy pod spodem jest baza czy coś imitującego.


@Saly: Dokładnie tak powinno być. Testując API nie interesuje Cię czy dane utrwalane są w bazie czy w plikach XML.

Chyba, że jak testujesz API to musisz mieć działającą bazkę? No to znów: kłania się separacja warstw. Bazka bazką, powinieneś móc testować API w izolacji, przy pomocy np InMemoryRepository, itp.

API to jest warstwa sklejająca
wolniejsze i drozsze,


@Hopsiup-siup: tutaj nie ma reguły, postawienie serwerwa HTTP to milisekundy. Takie testy mogą być setki razy szybsze od unitów

Unit testy niech sprawdzaja logike kodu i tyle.


@Hopsiup-siup: przy skomplikowanej integracji nie ma czegoś takiego jak logika kodu/logika zewnętrznych komponentów, bo sama integracja to większość logiki.
Chyba, że jak testujesz API to musisz mieć działającą bazkę? No to znów: kłania się separacja warstw. Bazka bazką, powinieneś móc testować API w izolacji, przy pomocy np InMemoryRepository, itp.


@MacDada: tak co nie zmienia faktu, że nie koniecznie chcę to robić. Mogę mieć wszystko ładnie podzielone a jednocześnie testować wszystko od poziomu API, bo uzna, że taka "filozofia" sprawi, że kod będzie jednocześnie najlepiej przetestowany jak się da przy dużo
co nie zmienia faktu, że nie koniecznie chcę to robić


@Saly: A, no to z chęciami dyskutować oczywiście nie będę ;-)

Mogę mieć wszystko ładnie podzielone a jednocześnie testować wszystko od poziomu API


@Saly: Spoko, tylko nie nazywaj tego wtedy testami jednostkowymi. To są testy funkcjonalne, integracyjne, a może wręcz edge-to-edge.

Takie testy też są potrzebne.

Problem jedynie taki, że wracamy do początku dyskusji: jak tu pisać TDD i pisać
@Saly: imo jeżeli testy API na zbudowanym środowisku są szybsze od testów jednostkowych to coś jest nie tak.

przy skomplikowanej integracji nie ma czegoś takiego jak logika kodu/logika zewnętrznych komponentów, bo sama integracja to większość logiki.


to mówisz o testach jednostkowych czy integracyjnych?
@MacDada: @Hopsiup-siup: generalnie problem bierze się stąd, że nie uznaję za bardzo różnicy pomiędzy testami jednostkowymi i integracyjnymi, bo ten podział według mnie nie ma sensu: za dużo sprzeczności i śliskich tematów. Dużo bardziej wolę np. podział z googla https://testing.googleblog.com/2010/12/test-sizes.html gdzie wszystko jest postawione czarno na białym a sam podział wnosi jakieś zalety

Tak czy owak typ testu nie wpływa na to jak się pisze test. Może być szybko przy
problem bierze się stąd, że nie uznaję za bardzo różnicy pomiędzy testami jednostkowymi i integracyjnymi


@Saly: No to naprawę państwa należy zacząć od naprawy pojęć ( ͡ ͜ʖ ͡)

Dużo bardziej wolę np. podział z googla https://testing.googleblog.com/2010/12/test-sizes.html


@Saly: Mi to wygląda na generalnie testy infrastruktury. To co oni nazywają testami małymi (60 sekund), dla mnie jest nieakceptowalnie długim testem (mówimy o czasie wykonywania ofc). No