[placebo_]

Test driven development - hot ot not? #programowanie

[CancerLight]

@placebo_: jeżeli piszesz testy to oznacza, że nie jesteś pewien tego co napisałeś ( ͡° ͜ʖ ͡°)

[keton22]

@placebo_: zero jednostkowych, jeden integracyjny...

[Saly]

@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]

@Saly: jak czekasz na jakieś kontenery to nie nazwałbym tego testem jednostkowym

[kobrys13]

jeden integracyjny

@keton22: i w ten sposób testujesz.tylko jedna ścieżkę?

[Hopsiup-siup]

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

[Saly]

@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

[MacDada]

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

[Saly]

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

[MacDada]

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,

[Saly]

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

[Hopsiup-siup]

@Saly: to o czym mowisz nie brzmi jak unit testy, testy API traktowalbym jako osobny zestaw testow [wolniejsze i drozsze, uruchamiane np na devie]. Unit testy niech sprawdzaja logike kodu i tyle.

[MacDada]

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

[MacDada]

jeżeli piszesz testy to oznacza, że nie jesteś pewien tego co napisałeś ( ͡° ͜ʖ ͡°)

@CancerLight: ( ͡° ͜ʖ ͡°)

[Saly]

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.

[Saly]

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

[MacDada]

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

[Hopsiup-siup]

@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?

[Saly]

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

[MacDada]

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