Kojarzycie jakąś w miarę działającą alternatywę dla RabbitMQ (implementującą ten sam protokół AMQP 0-9-1), która nie wstaje 15 sekund (btw. co tam się musi dziać pod spodem)? Jakieś pół roku temu robiłem szybki research i nie znalazłem nic, co by działało
0
0
Dlaczego akurat szybkość wstawania jest tutaj miernikiem wydajności? Jaki problem rozwiązuje Ci szybciej wstajaca kolejka, a nie np. jej przepustowość wiadomosci na sekundę?
4
mar-ek1 napisał(a):
Dlaczego akurat szybkość wstawania jest tutaj miernikiem wydajności? Jaki problem rozwiązuje Ci szybciej wstajaca kolejka, a nie np. jej przepustowość wiadomosci na sekundę?
No przecież widać że chce postawić fake'a do unit testów. A testy które trwają 15 sekund to przecież kaplica.
0
Racja, nie bylo tego w tresci i nie zauwazylem, że tytuł zawiera testy. Chociaż w sumie nie ma powoedziane o jakie testy chodzi, bo może być też kwestia uruchamiania kolejki raz dla wszystkich testów, zalezy od potrzeb
1
Google sugeruje np. https://qpid.apache.org/index.html bo można to odpalić embedded więc nie potrzeba ci tam jakiegoś testcontainers i czekania aż wstanie.
3
A nie można jakiegoś mocka zrobić? Przecież testy które sprawdzą wszystko nie będą odpalane cały czas i wtedy możesz tylko testować swoją część aplikacji, czyli czy tworzy ona wiadomości i reaguje na nowe.
5
.andy napisał(a):
A nie można jakiegoś mocka zrobić? Przecież testy które sprawdzą wszystko nie będą odpalane cały czas i wtedy możesz tylko testować swoją część aplikacji, czyli czy tworzy ona wiadomości i reaguje na nowe.
Wtedy testy będą mniej rzetelne, ciężej będzie je refaktorować i sam kod będzie ciężej zrefaktorować.
Innymi słowy wprowadzisz w testach niepotrzebny tight-coupling, czyli powód czemu 99% programistów nie lubi unit testów.
Pomysł @slsy żeby oprzeć testy na protokole zamiast na interfejsie biblioteki jest bardzo dobry.
2
@.andy: z jednej strony tak. Z drugiej strony nie lubię za dużej ilości mocków, bo one sprawdzają, czy mój kod działa tak jak myślę, gdzie tak naprawdę chodzi o sprawdzenie, czy mój kod działa. Np. nie wykryję jakiegoś corner case z d**y, który może być po stronie kolejki albo klienta do niej.
Inna zaleta to możliwość zmiany protokołu (np. na inną kolejkę). Jeśli zmiana kolejki sprawia, że jedyny kod w testach wymagający zmiany to czytanie wyników, to mam super testy, bo mogę sobie zmienić implementację oraz czytanie wyników i w teorii testy powinny dalej przechodzić
0
@.andy: z jednej strony tak. Z drugiej strony nie lubię za dużej ilości mocków, bo one sprawdzają, czy mój kod działa tak jak myślę, gdzie tak naprawdę chodzi o sprawdzenie, czy mój kod działa.
No ale tutaj sprawdzasz dwie kwestie. Czy twój kod się poprawnie integruje z kolejką, oraz czy twój kod potrafi poprawnie do niej uderzać i z niej czytać.
Jeśli zmiana kolejki sprawia
Jak często to to się dzieje? To tak jak ze zmianami silnika bazy danych. Niby można ale w 99% nikt tego nie robi na realnych projektach które żyją na produkcji i na siebie zarabiają.
1
.andy napisał(a):
@.andy: z jednej strony tak. Z drugiej strony nie lubię za dużej ilości mocków, bo one sprawdzają, czy mój kod działa tak jak myślę, gdzie tak naprawdę chodzi o sprawdzenie, czy mój kod działa.
No ale tutaj sprawdzasz dwie kwestie. Czy twój kod się poprawnie integruje z kolejką, oraz czy twój kod potrafi poprawnie do niej uderzać i z niej czytać.
Tak Ci się zdaje tylko.
Jeśli zmiana kolejki sprawia
Jak często to to się dzieje? To tak jak ze zmianami silnika bazy danych. Niby można ale w 99% nikt tego nie robi na realnych projektach które żyją na produkcji i na siebie zarabiają.
Ale toć nie chodzi o faktyczną "zmianę" tego rozwiązania, tylko o możliwość jego zmiany, nawet jeśli zmiana nigdy nie nastąpi.
Jeśli odpowiednio odseparujsz aplikację od interfejsu, to ta aplikacja będzie dużo bardziej utrzymywalna i lepiej zaprojektowana, niż gdyby te dwa byty były związane ze sobą.
Także tutaj chodzi o to żeby oddzielić zależności od siebie, a nie o to żeby faktycznie je zmieniać później.
0
Ale toć nie chodzi o faktyczną "zmianę" tego rozwiązania, tylko o możliwość jego zmiany, nawet jeśli zmiana nigdy nie nastąpi.
Zawsze można zrobić jakiś interfejs pośredniczący, który będzie taki sam a zmieni się tylko konkretna implementacja. Np. teraz używasz rabbita, to implementacja interfejsu jest pod rabita ale jak będziesz chciał pobawić się inną, to robisz drugą implementację.
0
No ale tutaj sprawdzasz dwie kwestie. Czy twój kod się poprawnie integruje z kolejką, oraz czy twój kod potrafi poprawnie do niej uderzać i z niej czytać.
@.andy: o każdym teście możesz tak powiedzieć. Jeśli wynikiem działania programu jest wrzucenie wiadomości do kolejki to nie da się tego robić inaczej niż poprzez podglądnięcie/wyciągnięcie elementów z tej kolejki. Analogicznie nie da się przetestować zapisu do bazy bez zrobienia weryfikacyjnego zapytania. W tym przypadku często wystarczy zawołać odpowiednią read metodę z API, dzięki czemu możemy przetestować czy persystencja działa jak należy bez dotykania bazy w testach. Analogicznie taki test assert "foo" = lower("FOO") zakłada, że poprawnie porównujemy stringi
Jak często to to się dzieje? To tak jak ze zmianami silnika bazy danych. Niby można ale w 99% nikt tego nie robi na realnych projektach które żyją na produkcji i na siebie zarabiają.
@.andy: myślę, że to dlatego, bo nie trzeba tego robić. Albo trzeba, ale ludzie się boją, bo nie mają testów, albo pomockowane repozytoria i ich domek z kart nie jest tak dobrze przetestowany jak myśleli xd
0
.andy napisał(a):
Ale toć nie chodzi o faktyczną "zmianę" tego rozwiązania, tylko o możliwość jego zmiany, nawet jeśli zmiana nigdy nie nastąpi.
Zawsze można zrobić jakiś interfejs pośredniczący, który będzie taki sam a zmieni się tylko konkretna implementacja. Np. teraz używasz rabbita, to implementacja interfejsu jest pod rabita ale jak będziesz chciał pobawić się inną, to robisz drugą implementację.
Mógłbyś, i wtedy da strona "bliżej projektu" faktycznie mogłaby być otestowana Twoim sposodem.
Ale nadal musisz otestować tą drugą stroną, "bliżej rabbita", i jedyny sposób żeby to zrobić to sposobem @slsy.
I może takie dzielenie w pewnych warunkach ma jakiś sens; np wtedy gdybyś faktycznie chciał zmienić biblioteke albo korzystać z dwóch na raz (że np user może sobie wybrać z której apka ma korzystać). Wtedy taki wysiłek byłby uzasadniony; tylko znowu, nie oszczędziłbyś sobie tym pracy; bo nadal nie uniknąłbyś stawiania lekkiego rabita do testów, bo i tak musisz przetestować tą integrację; a więc tylko dołożyłbyś sobie pracy, a nie oszczędził.
Ale jeśli nie musisz zmieniać libki; to testowanie tak jak @slsy pisał jest lepsze; a mocki to tylko niepotrzebne przywiązywanie testów do implementacji i stawianie sobie kłód pod nogi.
0
Mi się odpala w 3s. Ale zasadnicze pytanie w takim przypadku - to po co restartować Rabbita pomiędzy uruchomieniami testów?
0
hauleth napisał(a):
Mi się odpala w 3s. Ale zasadnicze pytanie w takim przypadku - to po co restartować Rabbita pomiędzy uruchomieniami testów?
W sensie podnieść dla całego suit'a i położyć później?
To nadal jest dupa, że jak chcesz odpalić tylko jeden test to z automatu masz 3s (czy jak @slsy nawet więcej) w dupę. Testy powinny być szybkie.
1
@TomRiddle: ja zwyczajnie zależności trzymam uruchomione pomiędzy testami. Więc wtedy problem tego czy DB wstaje 15s czy 1m, bo musi odbudować WAL nie ma specjalnie większego znaczenia, jak robię to raz dziennie. Więc już same uruchomienia testów na to nie wpływają.
A co do samego czasu, no to niespecjalnie przeskoczysz, bo BEAM nie jest demonem szybkości jeśli chodzi o czas startu. No po prostu trochę czasu zajmuje załadowanie wszystkich modułów i ich kompilacja (od czasu OTP 24, nie wiem jakiej wersji używa release, którego używa @slsy) + startup procesów wewnątrz VMki. Można pewnie użyć trochę magii i przyspieszyć czas ładowania kosztem runtime (moduły będą wtedy ładowane on-demand, a nie podczas uruchamiania), ale to pewnie może zepsuć parę rzeczy, więc niekoniecznie może mieć to sens.