Wątek przeniesiony 2020-03-08 22:38 z Java przez Shalom.

Granice testów jednostkowych

Odpowiedz Nowy wątek
2020-03-06 14:04

Rejestracja: 4 tygodnie temu

Ostatnio: 2 tygodnie temu

0

Czy pisząc test dla danej metody z jakiegoś serwisu uderzając do testowej bazy danych to nadal test jednostkowy? Czy już integracyjny? Gdzie zaczynają są granice testów jednostkowych? Czy pisząc taki test powinno się mockować odpowiedź czy używać bazy danych?

Dobre pytanie, też się chętnie dowiem gdzie są te granice. :) - Michał Sikora 2020-03-06 14:18

Pozostało 580 znaków

2020-03-06 15:08

Rejestracja: 3 lata temu

Ostatnio: 21 minut temu

Lokalizacja: U krasnoludów - pod górą

11

Jak już @Kamil Żabiński napisał:

Testy

Testy - jak są względnie szybkie i testują funkcjonalność to sa dobre - nawet jak podnoszą bazę danych, kontekts springowy, albo tylko ciśnienie.

Zawsze mnie dziwiło jak ktoś upiera, się że test z bazą w pamięci to integracyjny, a jak jest ta baza jest zamokowana hashmapą to już nie (mimo, że ta baza w pamięci (np. Key-value) mogła by być hashmapą...).

Jeżeli jakiś kawałek kodu robi wszystko grzebiąc po bazie danych to jej mokowanie jest stratą czasu.
Uważam pojęcie testów jednostkowych (i integracyjnych) za problematyczne, zwodnicze - niepotrzebnie zamieszanie.

Testy to testy.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 5x, ostatnio: jarekr000000, 2020-03-06 17:16

Pozostało 580 znaków

2020-03-06 15:12

Rejestracja: 5 lat temu

Ostatnio: 11 godzin temu

1
Shalom napisał(a):

@anonimowy

masz metodę

Nie masz bo testujesz funkcje systemu a nie metody albo ich argumenty. Poza tym twój argument jest inwalidą bo takie testy I TAK musisz mieć, bo inaczej nie masz żadnej pewności że coś faktycznie działa. To sie nazywa testy akceptacyjne.
Tak jak pisałem czasami są bardziej złożone kawałki kodu które trzeba przetestować jednostkowo, ale to jest kilka %

To nie rozumiem. Nie masz metod, które mają jakieś zasady biznesowe w sobie? Np

def get_member_time(user):
    if user.has_expired_time() or user.exceed_seeds():
        return 6
    if user.type not in ['asd', 'qwe']:
        return 8
    return 11

def get_parent_time(user):
    if (user.has_expired_time() and user.exceed_seeds()):
        return 6
    if user.type in ['asd', 'qwe']:
        return 5
    return 13

class SampleView(View):
    def get(self, request, *args, **kwargs):
        self.object = self.get_object()

        if get_member_time(self.object) > 10 or get_parent_time(self.object) > 10:
            # do someting else
        return super().get(request, *args, **kwargs)

W tym kodzie testowałbyś tylko SampleView? To albo musiałbyś testować if get_member_time(self.object) > 10 or get_parent_time(self.object) > 10: też linię na X sposobów albo mniej i po prostu przetestować metody get_time osobno

ja nie testuje takich małych metod. - mr_jaro 2020-03-06 15:16
To wyobraź sobie, że jest większa, to na szybko sobie napisałem od ręki bo nie chciało mi się wymyślać jakichś reguł biznesowych - anonimowy 2020-03-06 15:18

Pozostało 580 znaków

2020-03-06 15:16

Rejestracja: 3 lata temu

Ostatnio: 21 minut temu

Lokalizacja: U krasnoludów - pod górą

6

@anonimowy: tu choci o podejście i o cel.

Nie jest celem testowanie funkcji, metod czy klas. Tylko, o sprawdzenie czy dany komponent spełnia wymogi, zachowuje się poprawnie.
Zwykle to oznacza, że masz w komponencie jakieś metody (api), kóre wywołujesz i sprawdzasz czy wyniki się zgadzają.
Ale jeśli wyniki się zgadzają nawet bez istnienia metod to po prostu win-win. Kodu mniej, utrzymywać lżej.

W podanym przykładzie get_parent_time mogłoby być np, prywatne i wystarczyłby test na poziomie metody wyżej.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 2x, ostatnio: jarekr000000, 2020-03-06 15:19

Pozostało 580 znaków

2020-03-06 15:18

Rejestracja: 5 lat temu

Ostatnio: 11 godzin temu

1

Tylko jeśli chcesz mieć przetestowane wszystkie możliwości to musiałbyś mieć tych testów od groma

Pozostało 580 znaków

2020-03-06 15:20

Rejestracja: 3 lata temu

Ostatnio: 21 minut temu

Lokalizacja: U krasnoludów - pod górą

6

@anonimowy: dokładnie tyle samo. Jeśli jako możliwości masz na myśli ścieżki. Jeśli masz na myśli wszystkie inputy (np. dla Int) ... to żadne testowanie Ci tego łatwo nie zapewni.

Jeśli testujesz tylko "prywatne" elementy to masz masz często problem przy refaktoringu.
Po przeoraniu kodu, podzieleniu metod, przeniesieniu ich do innych klas trzeba całkiem przeorać testy... a to jakby niweczy samą ideę testów.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2020-03-06 15:23
Test jest integralną częścią kodu to logiczne, że trzeba go zmienić wraz ze znaczną zmianą kodu - anonimowy 2020-03-06 15:25
Testy mają zabezpieczać w razie refaktoringu, jeśli musisz znacznie zmieniać testy przy refaktoringu to jest problem. Oczywiście prawie zawsze coś trzeba zmieniać, kwestia jak dużo. - jarekr000000 2020-03-06 15:26
Nawet nie wiesz jak się cieszę, że słyszę takie słowa od kogoś z tylu letnim doświadczeniem. W końcu wychodzi, że nie jestem idiotą względem testów :D - mr_jaro 2020-03-06 15:28
Kiedy się ludzie nauczą :( , że jest tak jak @jarekr000000 mówi. Struktura i implementacja testów nie musi a wręcz nie powinna odwzorowywać struktury i implementacji kodu biznesowego. Kończy się betonem w którym system działa nadal prawidłowo a pierdylion testów się sypie jak domek z kart. - lsikora 2020-03-06 16:43
@lsikora: bywa lepiej, że testy zielone a system sypie się jak domki w kambodży :D to zresztą też właśnie domena takich przemockowanych testów jednostkowych. - Shalom 2020-03-06 16:56

Pozostało 580 znaków

2020-03-06 15:22

Rejestracja: 5 lat temu

Ostatnio: 11 godzin temu

0

W tym przypadku tyle samo ale jeśli np. w widoku doszedłby jeszcze jeden warunek to rośnie podwójnie

Pozostało 580 znaków

2020-03-06 15:29

Rejestracja: 3 lata temu

Ostatnio: 21 minut temu

Lokalizacja: U krasnoludów - pod górą

3

To co piszesz ma sens, ale ja to raczej widzę w drugą stronę - tak tworzę system, aby jego kawałki (metody, klasy) były sensownie testowalne. Nawet jeśli przez to czasem muszę zrobić coś pakietowo, modułowo dostępne (zamiast prywatnie). Znowu - to tylko kwestia intencji. Na koniec możemy mieć całkiem podobny kod.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2020-03-06 15:31

Pozostało 580 znaków

2020-03-06 16:04
Moderator

Rejestracja: 16 lat temu

Ostatnio: 13 godzin temu

3

@anonimowy spoko, to pisz sobie testy na poziomie takich mikro metod i potem przy każdej zmianie będziesz poświecać 2x więcej czasu na ich poprawnienie, mimo ze SYSTEM nadal działa i funkcje nadal działają. Tylko że to taki przykład złego testu -> jeśli system nadal działa a testy failują, to testy są zrypane (analogicznie oczywiście jeśli testy zielone a system nie działa to też można te testy zaorać).
Jasne że zmiany w kodzie pociagają zmiany w testach, ale jeśli musisz przepisać testy za każdym razem jak coś się zmienia, to jaka jest ich wartość? Co one ci tak realnie dają? Bo jak dla mnie takie testy sprawdzają tylko czy kod wygląda tak samo jak kiedy pisałem testy.

Jeszcze raz: ważne są funkcje systemu a nie jego wewnętrzne detale implementacyjne. To czy mój system ma serwis X albo metodę Y nie ma żadnego znaczenia. Ważne czy realizuje potrzebe biznesową.

edit:

W tym kodzie testowałbyś tylko SampleView? To albo musiałbyś testować if get_member_time(self.object) > 10 or get_parent_time(self.object) > 10: też linię na X sposobów albo mniej i po prostu przetestować metody get_time osobno

A jak inaczej? Przecież bez tego wcale nie wiesz czy to w ogóle działa :D to get_time może działać ok, a mimo wszystko w kupie to będzie działać źle. Klasyczne: https://ilkinulas.github.io/a[...]tests/no_integration_test.gif


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 3x, ostatnio: Shalom, 2020-03-06 16:08
Pokaż pozostałe 25 komentarzy
@Silv ale wdpenąłeś w bagno - dużo czytania : Roger Penrose, Bartosz Millewski (!), Brian Greene. Przykład: https://bartoszmilewski.com/2018/01/11/the-earth-is-flat/ - jarekr000000 2020-03-06 17:21
@Shalom no skoro zostawisz metodę, którą testujesz to chyba dobrze, że test nadal będzie zielony - anonimowy 2020-03-06 17:24
@jarekr000000: Jedynie Milewskiego widziałem, jak opowiadał o teorii kategorii; umie prowadzić wykłady opowiadać, nie przeczę. Dzięki, może kiedyś, jak znajdę czas, zobaczę, co Ci autorzy napisali. - Silv 2020-03-06 17:25
@Shalom: jeśli ta metoda testuje np. dodawanie to co w tym złego żeby był do niej test? - Inject 2020-03-06 17:25
@Inject: no jeśli biznesowo taką funkcje systemu udostępniasz to nie widzę problemu! Ale jeśli to jakiś wewnętrzny detal implementacji który dziś jest a jutro go nie ma, to marnujesz czas. @anonimowy nadal nie rozumiesz ze taki test nic nie mówi. Jak jest zielony to znaczy tylko że nikt nie dotykał danej metody a jak czerwony to znaczy że dotykał. Nie ma żadnego przełożenia na działanie lub niedziałanie systemu. Może być zielony a system nie działa, moze być czerwony a działa. Wartość takiego testu jest zerowa a w zasadzie ujemna bo tracisz czas na przepisywanie co chwila - Shalom 2020-03-06 17:29

Pozostało 580 znaków

2020-03-06 16:10

Rejestracja: 3 miesiące temu

Ostatnio: 1 dzień temu

0

Ale się temat rozkręcił! A prawda jest taka że to są wszystko miękkie granice. Czasem kilka testów trzeba napisać ale nie popadałbym w paranoję "100% coverage". Taką paranoję mają zwłaszcza ludzie którzy właśnie się dowiedzieli o testach jednostkowych ale nigdy ich na oczy w prawdziwej firmie nie widzieli.


Pozostało 580 znaków

2020-03-06 16:17

Rejestracja: 5 lat temu

Ostatnio: 11 godzin temu

0
Shalom napisał(a):

A jak inaczej? Przecież bez tego wcale nie wiesz czy to w ogóle działa :D

No to wtedy takie testy będą wiecznie trwać

Pokaż pozostałe 6 komentarzy
@Shalom: Serio, TDD oszczędziło mi mnóstwo czasu i mimo, że może nie być fajne itd. To uważam, że zaoszczędzony czas jest wystarczającym plusem - anonimowy 2020-03-08 16:13
@Shalom +1, ale watefall czasem ma sens wiec może TDD też czasem ma ;) - Miang 2020-03-08 16:17
@anonimowy: to jesteś w mniejszości, bo wszystkie badania na ten temat nie potwierdzają jakoby TDD powodowało oszczędność czasu (wręcz przeciwnie) albo wzrost jakości kodu. No ale jednym pomaga przepisywanie nono stop setek bezużytecznych testów, innym gumowa kaczka, nie mnie to oceniać. - Shalom 2020-03-08 16:20
Pokazałbyś te badania? Bo ja na sobie robiłem testy i przy TDD przeważnie wychodziłem na plus (nie zawsze ale przynajmniej były testy więc w dalszej perspektywie i tak na plus bym wyszedł) - anonimowy 2020-03-08 16:38

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0