Nowoczesne tworzenie aplikacji opiera si\u0119 na jednej prostej zasadzie:<\/p>\n\n\n\n
\nU\u017cyj kompozycji<\/b><\/p>\n<\/blockquote>\n\n\n\n\u0141\u0105czymy klasy, funkcje i us\u0142ugi w wi\u0119ksze fragmenty oprogramowania. Ten ostatni element jest podstaw\u0105 mikrous\u0142ugi<\/a> i architektura sze\u015bciok\u0105tna<\/a>. Chcieliby\u015bmy wykorzysta\u0107 istniej\u0105ce rozwi\u0105zania, zintegrowa\u0107 je z naszym oprogramowaniem i przej\u015b\u0107 bezpo\u015brednio do rynek<\/a>.<\/p>\n\n\n\nCzy chcesz obs\u0142ugiwa\u0107 rejestracj\u0119 konta i przechowywa\u0107 u\u017cytkownik\u00f3w? dane<\/a>? Mo\u017cesz wybra\u0107 jedn\u0105 z us\u0142ug OAuth. Mo\u017ce Twoja aplikacja oferuje jaki\u015b rodzaj subskrypcji lub p\u0142atno\u015bci? Istnieje wiele us\u0142ug, kt\u00f3re mog\u0105 ci w tym pom\u00f3c. Potrzebujesz analityki na swojej stronie internetowej, ale nie rozumiesz RODO<\/a>? Zapraszamy do skorzystania z jednego z gotowych rozwi\u0105za\u0144.<\/p>\n\n\n\nCo\u015b, co sprawia, \u017ce rozw\u00f3j jest tak \u0142atwy z biznesowego punktu widzenia, mo\u017ce przyprawi\u0107 o b\u00f3l g\u0142owy - w momencie, gdy trzeba napisa\u0107 prosty test.<\/p>\n\n\n\nFantastic Beasts: Kolejki, bazy danych i jak je testowa\u0107<\/h2>\n\n\n\nTestowanie jednostkowe jest do\u015b\u0107 proste. Je\u015bli b\u0119dziesz przestrzega\u0107 tylko tych zasad, to twoje \u015brodowisko testowe i kod<\/a> s\u0105 zdrowe. Jakie to zasady?<\/p>\n\n\n\n\n\u0141atwo\u015b\u0107 pisania<\/b> - Testy jednostkowe powinny by\u0107 \u0142atwe do napisania, poniewa\u017c pisze si\u0119 ich du\u017co. Mniejszy wysi\u0142ek oznacza wi\u0119cej napisanych test\u00f3w.<\/li>\n\n\n\nCzytelny<\/b> - kod testu powinien by\u0107 \u0142atwy do odczytania. Test jest histori\u0105. Opisuje zachowanie oprogramowania i mo\u017ce by\u0107 u\u017cywany jako skr\u00f3t dokumentacji. Dobry test jednostkowy pomaga naprawi\u0107 b\u0142\u0119dy bez debugowania kodu.<\/li>\n\n\n\nNiezawodny<\/b> - test powinien zako\u0144czy\u0107 si\u0119 niepowodzeniem tylko wtedy, gdy w testowanym systemie wyst\u0119puje b\u0142\u0105d. Oczywiste? Nie zawsze. Czasami testy przechodz\u0105 pomy\u015blnie, je\u015bli uruchamiasz je pojedynczo, ale ko\u0144cz\u0105 si\u0119 niepowodzeniem, gdy uruchamiasz je jako zestaw. Przechodz\u0105 pomy\u015blnie na Twojej maszynie, ale ko\u0144cz\u0105 si\u0119 niepowodzeniem na CI (Dzia\u0142a na moim komputerze<\/a>). Dobry test jednostkowy ma tylko jedn\u0105 przyczyn\u0119 niepowodzenia.<\/li>\n\n\n\nSzybko<\/b> - testy powinny by\u0107 szybkie. Przygotowanie do uruchomienia, uruchomienie i samo wykonanie testu powinno by\u0107 bardzo szybkie. W przeciwnym razie b\u0119dziesz je pisa\u0107, ale nie uruchamia\u0107. Wolne testy oznaczaj\u0105 utrat\u0119 koncentracji. Czekasz i patrzysz na pasek post\u0119pu.<\/li>\n\n\n\nNiezale\u017cny<\/b> - wreszcie, test powinien by\u0107 niezale\u017cny. Ta zasada wynika z poprzednich. Tylko prawdziwie niezale\u017cne testy mog\u0105 sta\u0107 si\u0119 jednostk\u0105. Nie koliduj\u0105 one ze sob\u0105, mog\u0105 by\u0107 uruchamiane w dowolnej kolejno\u015bci, a potencjalne awarie nie zale\u017c\u0105 od wynik\u00f3w innych test\u00f3w. Niezale\u017cno\u015b\u0107 oznacza r\u00f3wnie\u017c brak zale\u017cno\u015bci od jakichkolwiek zewn\u0119trznych zasob\u00f3w, takich jak bazy danych, us\u0142ugi przesy\u0142ania wiadomo\u015bci lub system plik\u00f3w. Je\u015bli musisz komunikowa\u0107 si\u0119 z zewn\u0119trznymi zasobami, mo\u017cesz u\u017cy\u0107 makiet, stub\u00f3w lub manekin\u00f3w.<\/li>\n<\/ul>\n\n\n\nWszystko staje si\u0119 skomplikowane, gdy chcemy napisa\u0107 testy integracyjne. Nie jest \u017ale, je\u015bli chcemy przetestowa\u0107 kilka us\u0142ug razem. Ale kiedy musimy przetestowa\u0107 us\u0142ugi, kt\u00f3re korzystaj\u0105 z zewn\u0119trznych zasob\u00f3w, takich jak bazy danych lub us\u0142ugi przesy\u0142ania wiadomo\u015bci, wtedy prosimy o k\u0142opoty.<\/p>\n\n\n\nAby uruchomi\u0107 test, nale\u017cy zainstalowa\u0107...<\/h3>\n\n\n\nWiele lat temu, gdy chcieli\u015bmy wykona\u0107 testy integracyjne i wykorzysta\u0107 np. bazy danych, mieli\u015bmy dwie opcje:<\/p>\n\n\n\n\nMo\u017cemy zainstalowa\u0107 baz\u0119 danych lokalnie. Skonfiguruj schemat i po\u0142\u0105cz si\u0119 z naszego testu;<\/li>\n\n\n\nMo\u017cemy po\u0142\u0105czy\u0107 si\u0119 z istniej\u0105c\u0105 instancj\u0105 \"gdzie\u015b w przestrzeni\".<\/li>\n<\/ol>\n\n\n\nOba rozwi\u0105zania maj\u0105 swoje plusy i minusy. Ale oba wprowadzaj\u0105 dodatkowe poziomy z\u0142o\u017cono\u015bci. Czasami by\u0142a to z\u0142o\u017cono\u015b\u0107 techniczna wynikaj\u0105ca z charakterystyki niekt\u00f3rych narz\u0119dzi, np. instalacja i zarz\u0105dzanie Oracle DB na lokalnym ho\u015bcie. Czasami by\u0142a to niedogodno\u015b\u0107 w procesie, np. konieczno\u015b\u0107 uzgodnienia z testerem zesp\u00f3\u0142<\/a> o wykorzystaniu JMS... za ka\u017cdym razem, gdy chcesz uruchomi\u0107 testy.<\/p>\n\n\n\nKontenery na ratunek<\/h3>\n\n\n\nW ci\u0105gu ostatnich 10 lat idea konteneryzacji zyska\u0142a uznanie w bran\u017cy. Naturaln\u0105 decyzj\u0105 by\u0142o wi\u0119c wybranie kontener\u00f3w jako rozwi\u0105zania dla naszej kwestii test\u00f3w integracyjnych. Jest to proste, czyste rozwi\u0105zanie. Wystarczy uruchomi\u0107 kompilacj\u0119 procesu i wszystko dzia\u0142a! Nie mo\u017cesz w to uwierzy\u0107? Sp\u00f3jrz na t\u0119 prost\u0105 konfiguracj\u0119 kompilacji maven:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-compile\n \n up\n \n \n ${projekt<\/a>.basedir}\/docker-compose.yml\n true.\n \n \n \n down\n post-integration-test\n \n down\n \n \n ${project.basedir}\/docker-compose.yml\n true.<\/code><\/pre>\n\n\n\nI docker-compose.yml<\/code> Plik te\u017c wygl\u0105da ca\u0142kiem nie\u017ale!<\/p>\n\n\n\nwersja: \"3.5\"\n\nus\u0142ugi:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: zawsze\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=has\u0142o\n - POSTGRES_DB=miasta\n porty:\n - \"5432:5432\"\n wolumeny:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: zawsze\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: has\u0142o\n porty:\n - \"15050:80\"\n wolumeny:\n - pgadmin_data:\/data\/pgadmin\n\nwolumeny:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nAle czy dostrzegasz tutaj problem?<\/p>\n\n\n\nStatek towarowy, kt\u00f3ry blokuje wszystko<\/h3>\n\n\n\nPowy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
U\u017cyj kompozycji<\/b><\/p>\n<\/blockquote>\n\n\n\n
\u0141\u0105czymy klasy, funkcje i us\u0142ugi w wi\u0119ksze fragmenty oprogramowania. Ten ostatni element jest podstaw\u0105 mikrous\u0142ugi<\/a> i architektura sze\u015bciok\u0105tna<\/a>. Chcieliby\u015bmy wykorzysta\u0107 istniej\u0105ce rozwi\u0105zania, zintegrowa\u0107 je z naszym oprogramowaniem i przej\u015b\u0107 bezpo\u015brednio do rynek<\/a>.<\/p>\n\n\n\nCzy chcesz obs\u0142ugiwa\u0107 rejestracj\u0119 konta i przechowywa\u0107 u\u017cytkownik\u00f3w? dane<\/a>? Mo\u017cesz wybra\u0107 jedn\u0105 z us\u0142ug OAuth. Mo\u017ce Twoja aplikacja oferuje jaki\u015b rodzaj subskrypcji lub p\u0142atno\u015bci? Istnieje wiele us\u0142ug, kt\u00f3re mog\u0105 ci w tym pom\u00f3c. Potrzebujesz analityki na swojej stronie internetowej, ale nie rozumiesz RODO<\/a>? Zapraszamy do skorzystania z jednego z gotowych rozwi\u0105za\u0144.<\/p>\n\n\n\nCo\u015b, co sprawia, \u017ce rozw\u00f3j jest tak \u0142atwy z biznesowego punktu widzenia, mo\u017ce przyprawi\u0107 o b\u00f3l g\u0142owy - w momencie, gdy trzeba napisa\u0107 prosty test.<\/p>\n\n\n\nFantastic Beasts: Kolejki, bazy danych i jak je testowa\u0107<\/h2>\n\n\n\nTestowanie jednostkowe jest do\u015b\u0107 proste. Je\u015bli b\u0119dziesz przestrzega\u0107 tylko tych zasad, to twoje \u015brodowisko testowe i kod<\/a> s\u0105 zdrowe. Jakie to zasady?<\/p>\n\n\n\n\n\u0141atwo\u015b\u0107 pisania<\/b> - Testy jednostkowe powinny by\u0107 \u0142atwe do napisania, poniewa\u017c pisze si\u0119 ich du\u017co. Mniejszy wysi\u0142ek oznacza wi\u0119cej napisanych test\u00f3w.<\/li>\n\n\n\nCzytelny<\/b> - kod testu powinien by\u0107 \u0142atwy do odczytania. Test jest histori\u0105. Opisuje zachowanie oprogramowania i mo\u017ce by\u0107 u\u017cywany jako skr\u00f3t dokumentacji. Dobry test jednostkowy pomaga naprawi\u0107 b\u0142\u0119dy bez debugowania kodu.<\/li>\n\n\n\nNiezawodny<\/b> - test powinien zako\u0144czy\u0107 si\u0119 niepowodzeniem tylko wtedy, gdy w testowanym systemie wyst\u0119puje b\u0142\u0105d. Oczywiste? Nie zawsze. Czasami testy przechodz\u0105 pomy\u015blnie, je\u015bli uruchamiasz je pojedynczo, ale ko\u0144cz\u0105 si\u0119 niepowodzeniem, gdy uruchamiasz je jako zestaw. Przechodz\u0105 pomy\u015blnie na Twojej maszynie, ale ko\u0144cz\u0105 si\u0119 niepowodzeniem na CI (Dzia\u0142a na moim komputerze<\/a>). Dobry test jednostkowy ma tylko jedn\u0105 przyczyn\u0119 niepowodzenia.<\/li>\n\n\n\nSzybko<\/b> - testy powinny by\u0107 szybkie. Przygotowanie do uruchomienia, uruchomienie i samo wykonanie testu powinno by\u0107 bardzo szybkie. W przeciwnym razie b\u0119dziesz je pisa\u0107, ale nie uruchamia\u0107. Wolne testy oznaczaj\u0105 utrat\u0119 koncentracji. Czekasz i patrzysz na pasek post\u0119pu.<\/li>\n\n\n\nNiezale\u017cny<\/b> - wreszcie, test powinien by\u0107 niezale\u017cny. Ta zasada wynika z poprzednich. Tylko prawdziwie niezale\u017cne testy mog\u0105 sta\u0107 si\u0119 jednostk\u0105. Nie koliduj\u0105 one ze sob\u0105, mog\u0105 by\u0107 uruchamiane w dowolnej kolejno\u015bci, a potencjalne awarie nie zale\u017c\u0105 od wynik\u00f3w innych test\u00f3w. Niezale\u017cno\u015b\u0107 oznacza r\u00f3wnie\u017c brak zale\u017cno\u015bci od jakichkolwiek zewn\u0119trznych zasob\u00f3w, takich jak bazy danych, us\u0142ugi przesy\u0142ania wiadomo\u015bci lub system plik\u00f3w. Je\u015bli musisz komunikowa\u0107 si\u0119 z zewn\u0119trznymi zasobami, mo\u017cesz u\u017cy\u0107 makiet, stub\u00f3w lub manekin\u00f3w.<\/li>\n<\/ul>\n\n\n\nWszystko staje si\u0119 skomplikowane, gdy chcemy napisa\u0107 testy integracyjne. Nie jest \u017ale, je\u015bli chcemy przetestowa\u0107 kilka us\u0142ug razem. Ale kiedy musimy przetestowa\u0107 us\u0142ugi, kt\u00f3re korzystaj\u0105 z zewn\u0119trznych zasob\u00f3w, takich jak bazy danych lub us\u0142ugi przesy\u0142ania wiadomo\u015bci, wtedy prosimy o k\u0142opoty.<\/p>\n\n\n\nAby uruchomi\u0107 test, nale\u017cy zainstalowa\u0107...<\/h3>\n\n\n\nWiele lat temu, gdy chcieli\u015bmy wykona\u0107 testy integracyjne i wykorzysta\u0107 np. bazy danych, mieli\u015bmy dwie opcje:<\/p>\n\n\n\n\nMo\u017cemy zainstalowa\u0107 baz\u0119 danych lokalnie. Skonfiguruj schemat i po\u0142\u0105cz si\u0119 z naszego testu;<\/li>\n\n\n\nMo\u017cemy po\u0142\u0105czy\u0107 si\u0119 z istniej\u0105c\u0105 instancj\u0105 \"gdzie\u015b w przestrzeni\".<\/li>\n<\/ol>\n\n\n\nOba rozwi\u0105zania maj\u0105 swoje plusy i minusy. Ale oba wprowadzaj\u0105 dodatkowe poziomy z\u0142o\u017cono\u015bci. Czasami by\u0142a to z\u0142o\u017cono\u015b\u0107 techniczna wynikaj\u0105ca z charakterystyki niekt\u00f3rych narz\u0119dzi, np. instalacja i zarz\u0105dzanie Oracle DB na lokalnym ho\u015bcie. Czasami by\u0142a to niedogodno\u015b\u0107 w procesie, np. konieczno\u015b\u0107 uzgodnienia z testerem zesp\u00f3\u0142<\/a> o wykorzystaniu JMS... za ka\u017cdym razem, gdy chcesz uruchomi\u0107 testy.<\/p>\n\n\n\nKontenery na ratunek<\/h3>\n\n\n\nW ci\u0105gu ostatnich 10 lat idea konteneryzacji zyska\u0142a uznanie w bran\u017cy. Naturaln\u0105 decyzj\u0105 by\u0142o wi\u0119c wybranie kontener\u00f3w jako rozwi\u0105zania dla naszej kwestii test\u00f3w integracyjnych. Jest to proste, czyste rozwi\u0105zanie. Wystarczy uruchomi\u0107 kompilacj\u0119 procesu i wszystko dzia\u0142a! Nie mo\u017cesz w to uwierzy\u0107? Sp\u00f3jrz na t\u0119 prost\u0105 konfiguracj\u0119 kompilacji maven:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-compile\n \n up\n \n \n ${projekt<\/a>.basedir}\/docker-compose.yml\n true.\n \n \n \n down\n post-integration-test\n \n down\n \n \n ${project.basedir}\/docker-compose.yml\n true.<\/code><\/pre>\n\n\n\nI docker-compose.yml<\/code> Plik te\u017c wygl\u0105da ca\u0142kiem nie\u017ale!<\/p>\n\n\n\nwersja: \"3.5\"\n\nus\u0142ugi:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: zawsze\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=has\u0142o\n - POSTGRES_DB=miasta\n porty:\n - \"5432:5432\"\n wolumeny:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: zawsze\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: has\u0142o\n porty:\n - \"15050:80\"\n wolumeny:\n - pgadmin_data:\/data\/pgadmin\n\nwolumeny:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nAle czy dostrzegasz tutaj problem?<\/p>\n\n\n\nStatek towarowy, kt\u00f3ry blokuje wszystko<\/h3>\n\n\n\nPowy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
Czy chcesz obs\u0142ugiwa\u0107 rejestracj\u0119 konta i przechowywa\u0107 u\u017cytkownik\u00f3w? dane<\/a>? Mo\u017cesz wybra\u0107 jedn\u0105 z us\u0142ug OAuth. Mo\u017ce Twoja aplikacja oferuje jaki\u015b rodzaj subskrypcji lub p\u0142atno\u015bci? Istnieje wiele us\u0142ug, kt\u00f3re mog\u0105 ci w tym pom\u00f3c. Potrzebujesz analityki na swojej stronie internetowej, ale nie rozumiesz RODO<\/a>? Zapraszamy do skorzystania z jednego z gotowych rozwi\u0105za\u0144.<\/p>\n\n\n\nCo\u015b, co sprawia, \u017ce rozw\u00f3j jest tak \u0142atwy z biznesowego punktu widzenia, mo\u017ce przyprawi\u0107 o b\u00f3l g\u0142owy - w momencie, gdy trzeba napisa\u0107 prosty test.<\/p>\n\n\n\nFantastic Beasts: Kolejki, bazy danych i jak je testowa\u0107<\/h2>\n\n\n\nTestowanie jednostkowe jest do\u015b\u0107 proste. Je\u015bli b\u0119dziesz przestrzega\u0107 tylko tych zasad, to twoje \u015brodowisko testowe i kod<\/a> s\u0105 zdrowe. Jakie to zasady?<\/p>\n\n\n\n\n\u0141atwo\u015b\u0107 pisania<\/b> - Testy jednostkowe powinny by\u0107 \u0142atwe do napisania, poniewa\u017c pisze si\u0119 ich du\u017co. Mniejszy wysi\u0142ek oznacza wi\u0119cej napisanych test\u00f3w.<\/li>\n\n\n\nCzytelny<\/b> - kod testu powinien by\u0107 \u0142atwy do odczytania. Test jest histori\u0105. Opisuje zachowanie oprogramowania i mo\u017ce by\u0107 u\u017cywany jako skr\u00f3t dokumentacji. Dobry test jednostkowy pomaga naprawi\u0107 b\u0142\u0119dy bez debugowania kodu.<\/li>\n\n\n\nNiezawodny<\/b> - test powinien zako\u0144czy\u0107 si\u0119 niepowodzeniem tylko wtedy, gdy w testowanym systemie wyst\u0119puje b\u0142\u0105d. Oczywiste? Nie zawsze. Czasami testy przechodz\u0105 pomy\u015blnie, je\u015bli uruchamiasz je pojedynczo, ale ko\u0144cz\u0105 si\u0119 niepowodzeniem, gdy uruchamiasz je jako zestaw. Przechodz\u0105 pomy\u015blnie na Twojej maszynie, ale ko\u0144cz\u0105 si\u0119 niepowodzeniem na CI (Dzia\u0142a na moim komputerze<\/a>). Dobry test jednostkowy ma tylko jedn\u0105 przyczyn\u0119 niepowodzenia.<\/li>\n\n\n\nSzybko<\/b> - testy powinny by\u0107 szybkie. Przygotowanie do uruchomienia, uruchomienie i samo wykonanie testu powinno by\u0107 bardzo szybkie. W przeciwnym razie b\u0119dziesz je pisa\u0107, ale nie uruchamia\u0107. Wolne testy oznaczaj\u0105 utrat\u0119 koncentracji. Czekasz i patrzysz na pasek post\u0119pu.<\/li>\n\n\n\nNiezale\u017cny<\/b> - wreszcie, test powinien by\u0107 niezale\u017cny. Ta zasada wynika z poprzednich. Tylko prawdziwie niezale\u017cne testy mog\u0105 sta\u0107 si\u0119 jednostk\u0105. Nie koliduj\u0105 one ze sob\u0105, mog\u0105 by\u0107 uruchamiane w dowolnej kolejno\u015bci, a potencjalne awarie nie zale\u017c\u0105 od wynik\u00f3w innych test\u00f3w. Niezale\u017cno\u015b\u0107 oznacza r\u00f3wnie\u017c brak zale\u017cno\u015bci od jakichkolwiek zewn\u0119trznych zasob\u00f3w, takich jak bazy danych, us\u0142ugi przesy\u0142ania wiadomo\u015bci lub system plik\u00f3w. Je\u015bli musisz komunikowa\u0107 si\u0119 z zewn\u0119trznymi zasobami, mo\u017cesz u\u017cy\u0107 makiet, stub\u00f3w lub manekin\u00f3w.<\/li>\n<\/ul>\n\n\n\nWszystko staje si\u0119 skomplikowane, gdy chcemy napisa\u0107 testy integracyjne. Nie jest \u017ale, je\u015bli chcemy przetestowa\u0107 kilka us\u0142ug razem. Ale kiedy musimy przetestowa\u0107 us\u0142ugi, kt\u00f3re korzystaj\u0105 z zewn\u0119trznych zasob\u00f3w, takich jak bazy danych lub us\u0142ugi przesy\u0142ania wiadomo\u015bci, wtedy prosimy o k\u0142opoty.<\/p>\n\n\n\nAby uruchomi\u0107 test, nale\u017cy zainstalowa\u0107...<\/h3>\n\n\n\nWiele lat temu, gdy chcieli\u015bmy wykona\u0107 testy integracyjne i wykorzysta\u0107 np. bazy danych, mieli\u015bmy dwie opcje:<\/p>\n\n\n\n\nMo\u017cemy zainstalowa\u0107 baz\u0119 danych lokalnie. Skonfiguruj schemat i po\u0142\u0105cz si\u0119 z naszego testu;<\/li>\n\n\n\nMo\u017cemy po\u0142\u0105czy\u0107 si\u0119 z istniej\u0105c\u0105 instancj\u0105 \"gdzie\u015b w przestrzeni\".<\/li>\n<\/ol>\n\n\n\nOba rozwi\u0105zania maj\u0105 swoje plusy i minusy. Ale oba wprowadzaj\u0105 dodatkowe poziomy z\u0142o\u017cono\u015bci. Czasami by\u0142a to z\u0142o\u017cono\u015b\u0107 techniczna wynikaj\u0105ca z charakterystyki niekt\u00f3rych narz\u0119dzi, np. instalacja i zarz\u0105dzanie Oracle DB na lokalnym ho\u015bcie. Czasami by\u0142a to niedogodno\u015b\u0107 w procesie, np. konieczno\u015b\u0107 uzgodnienia z testerem zesp\u00f3\u0142<\/a> o wykorzystaniu JMS... za ka\u017cdym razem, gdy chcesz uruchomi\u0107 testy.<\/p>\n\n\n\nKontenery na ratunek<\/h3>\n\n\n\nW ci\u0105gu ostatnich 10 lat idea konteneryzacji zyska\u0142a uznanie w bran\u017cy. Naturaln\u0105 decyzj\u0105 by\u0142o wi\u0119c wybranie kontener\u00f3w jako rozwi\u0105zania dla naszej kwestii test\u00f3w integracyjnych. Jest to proste, czyste rozwi\u0105zanie. Wystarczy uruchomi\u0107 kompilacj\u0119 procesu i wszystko dzia\u0142a! Nie mo\u017cesz w to uwierzy\u0107? Sp\u00f3jrz na t\u0119 prost\u0105 konfiguracj\u0119 kompilacji maven:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-compile\n \n up\n \n \n ${projekt<\/a>.basedir}\/docker-compose.yml\n true.\n \n \n \n down\n post-integration-test\n \n down\n \n \n ${project.basedir}\/docker-compose.yml\n true.<\/code><\/pre>\n\n\n\nI docker-compose.yml<\/code> Plik te\u017c wygl\u0105da ca\u0142kiem nie\u017ale!<\/p>\n\n\n\nwersja: \"3.5\"\n\nus\u0142ugi:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: zawsze\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=has\u0142o\n - POSTGRES_DB=miasta\n porty:\n - \"5432:5432\"\n wolumeny:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: zawsze\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: has\u0142o\n porty:\n - \"15050:80\"\n wolumeny:\n - pgadmin_data:\/data\/pgadmin\n\nwolumeny:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nAle czy dostrzegasz tutaj problem?<\/p>\n\n\n\nStatek towarowy, kt\u00f3ry blokuje wszystko<\/h3>\n\n\n\nPowy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
Co\u015b, co sprawia, \u017ce rozw\u00f3j jest tak \u0142atwy z biznesowego punktu widzenia, mo\u017ce przyprawi\u0107 o b\u00f3l g\u0142owy - w momencie, gdy trzeba napisa\u0107 prosty test.<\/p>\n\n\n\n
Testowanie jednostkowe jest do\u015b\u0107 proste. Je\u015bli b\u0119dziesz przestrzega\u0107 tylko tych zasad, to twoje \u015brodowisko testowe i kod<\/a> s\u0105 zdrowe. Jakie to zasady?<\/p>\n\n\n\n\n\u0141atwo\u015b\u0107 pisania<\/b> - Testy jednostkowe powinny by\u0107 \u0142atwe do napisania, poniewa\u017c pisze si\u0119 ich du\u017co. Mniejszy wysi\u0142ek oznacza wi\u0119cej napisanych test\u00f3w.<\/li>\n\n\n\nCzytelny<\/b> - kod testu powinien by\u0107 \u0142atwy do odczytania. Test jest histori\u0105. Opisuje zachowanie oprogramowania i mo\u017ce by\u0107 u\u017cywany jako skr\u00f3t dokumentacji. Dobry test jednostkowy pomaga naprawi\u0107 b\u0142\u0119dy bez debugowania kodu.<\/li>\n\n\n\nNiezawodny<\/b> - test powinien zako\u0144czy\u0107 si\u0119 niepowodzeniem tylko wtedy, gdy w testowanym systemie wyst\u0119puje b\u0142\u0105d. Oczywiste? Nie zawsze. Czasami testy przechodz\u0105 pomy\u015blnie, je\u015bli uruchamiasz je pojedynczo, ale ko\u0144cz\u0105 si\u0119 niepowodzeniem, gdy uruchamiasz je jako zestaw. Przechodz\u0105 pomy\u015blnie na Twojej maszynie, ale ko\u0144cz\u0105 si\u0119 niepowodzeniem na CI (Dzia\u0142a na moim komputerze<\/a>). Dobry test jednostkowy ma tylko jedn\u0105 przyczyn\u0119 niepowodzenia.<\/li>\n\n\n\nSzybko<\/b> - testy powinny by\u0107 szybkie. Przygotowanie do uruchomienia, uruchomienie i samo wykonanie testu powinno by\u0107 bardzo szybkie. W przeciwnym razie b\u0119dziesz je pisa\u0107, ale nie uruchamia\u0107. Wolne testy oznaczaj\u0105 utrat\u0119 koncentracji. Czekasz i patrzysz na pasek post\u0119pu.<\/li>\n\n\n\nNiezale\u017cny<\/b> - wreszcie, test powinien by\u0107 niezale\u017cny. Ta zasada wynika z poprzednich. Tylko prawdziwie niezale\u017cne testy mog\u0105 sta\u0107 si\u0119 jednostk\u0105. Nie koliduj\u0105 one ze sob\u0105, mog\u0105 by\u0107 uruchamiane w dowolnej kolejno\u015bci, a potencjalne awarie nie zale\u017c\u0105 od wynik\u00f3w innych test\u00f3w. Niezale\u017cno\u015b\u0107 oznacza r\u00f3wnie\u017c brak zale\u017cno\u015bci od jakichkolwiek zewn\u0119trznych zasob\u00f3w, takich jak bazy danych, us\u0142ugi przesy\u0142ania wiadomo\u015bci lub system plik\u00f3w. Je\u015bli musisz komunikowa\u0107 si\u0119 z zewn\u0119trznymi zasobami, mo\u017cesz u\u017cy\u0107 makiet, stub\u00f3w lub manekin\u00f3w.<\/li>\n<\/ul>\n\n\n\nWszystko staje si\u0119 skomplikowane, gdy chcemy napisa\u0107 testy integracyjne. Nie jest \u017ale, je\u015bli chcemy przetestowa\u0107 kilka us\u0142ug razem. Ale kiedy musimy przetestowa\u0107 us\u0142ugi, kt\u00f3re korzystaj\u0105 z zewn\u0119trznych zasob\u00f3w, takich jak bazy danych lub us\u0142ugi przesy\u0142ania wiadomo\u015bci, wtedy prosimy o k\u0142opoty.<\/p>\n\n\n\nAby uruchomi\u0107 test, nale\u017cy zainstalowa\u0107...<\/h3>\n\n\n\nWiele lat temu, gdy chcieli\u015bmy wykona\u0107 testy integracyjne i wykorzysta\u0107 np. bazy danych, mieli\u015bmy dwie opcje:<\/p>\n\n\n\n\nMo\u017cemy zainstalowa\u0107 baz\u0119 danych lokalnie. Skonfiguruj schemat i po\u0142\u0105cz si\u0119 z naszego testu;<\/li>\n\n\n\nMo\u017cemy po\u0142\u0105czy\u0107 si\u0119 z istniej\u0105c\u0105 instancj\u0105 \"gdzie\u015b w przestrzeni\".<\/li>\n<\/ol>\n\n\n\nOba rozwi\u0105zania maj\u0105 swoje plusy i minusy. Ale oba wprowadzaj\u0105 dodatkowe poziomy z\u0142o\u017cono\u015bci. Czasami by\u0142a to z\u0142o\u017cono\u015b\u0107 techniczna wynikaj\u0105ca z charakterystyki niekt\u00f3rych narz\u0119dzi, np. instalacja i zarz\u0105dzanie Oracle DB na lokalnym ho\u015bcie. Czasami by\u0142a to niedogodno\u015b\u0107 w procesie, np. konieczno\u015b\u0107 uzgodnienia z testerem zesp\u00f3\u0142<\/a> o wykorzystaniu JMS... za ka\u017cdym razem, gdy chcesz uruchomi\u0107 testy.<\/p>\n\n\n\nKontenery na ratunek<\/h3>\n\n\n\nW ci\u0105gu ostatnich 10 lat idea konteneryzacji zyska\u0142a uznanie w bran\u017cy. Naturaln\u0105 decyzj\u0105 by\u0142o wi\u0119c wybranie kontener\u00f3w jako rozwi\u0105zania dla naszej kwestii test\u00f3w integracyjnych. Jest to proste, czyste rozwi\u0105zanie. Wystarczy uruchomi\u0107 kompilacj\u0119 procesu i wszystko dzia\u0142a! Nie mo\u017cesz w to uwierzy\u0107? Sp\u00f3jrz na t\u0119 prost\u0105 konfiguracj\u0119 kompilacji maven:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-compile\n \n up\n \n \n ${projekt<\/a>.basedir}\/docker-compose.yml\n true.\n \n \n \n down\n post-integration-test\n \n down\n \n \n ${project.basedir}\/docker-compose.yml\n true.<\/code><\/pre>\n\n\n\nI docker-compose.yml<\/code> Plik te\u017c wygl\u0105da ca\u0142kiem nie\u017ale!<\/p>\n\n\n\nwersja: \"3.5\"\n\nus\u0142ugi:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: zawsze\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=has\u0142o\n - POSTGRES_DB=miasta\n porty:\n - \"5432:5432\"\n wolumeny:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: zawsze\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: has\u0142o\n porty:\n - \"15050:80\"\n wolumeny:\n - pgadmin_data:\/data\/pgadmin\n\nwolumeny:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nAle czy dostrzegasz tutaj problem?<\/p>\n\n\n\nStatek towarowy, kt\u00f3ry blokuje wszystko<\/h3>\n\n\n\nPowy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
Wszystko staje si\u0119 skomplikowane, gdy chcemy napisa\u0107 testy integracyjne. Nie jest \u017ale, je\u015bli chcemy przetestowa\u0107 kilka us\u0142ug razem. Ale kiedy musimy przetestowa\u0107 us\u0142ugi, kt\u00f3re korzystaj\u0105 z zewn\u0119trznych zasob\u00f3w, takich jak bazy danych lub us\u0142ugi przesy\u0142ania wiadomo\u015bci, wtedy prosimy o k\u0142opoty.<\/p>\n\n\n\n
Wiele lat temu, gdy chcieli\u015bmy wykona\u0107 testy integracyjne i wykorzysta\u0107 np. bazy danych, mieli\u015bmy dwie opcje:<\/p>\n\n\n\n
Oba rozwi\u0105zania maj\u0105 swoje plusy i minusy. Ale oba wprowadzaj\u0105 dodatkowe poziomy z\u0142o\u017cono\u015bci. Czasami by\u0142a to z\u0142o\u017cono\u015b\u0107 techniczna wynikaj\u0105ca z charakterystyki niekt\u00f3rych narz\u0119dzi, np. instalacja i zarz\u0105dzanie Oracle DB na lokalnym ho\u015bcie. Czasami by\u0142a to niedogodno\u015b\u0107 w procesie, np. konieczno\u015b\u0107 uzgodnienia z testerem zesp\u00f3\u0142<\/a> o wykorzystaniu JMS... za ka\u017cdym razem, gdy chcesz uruchomi\u0107 testy.<\/p>\n\n\n\nKontenery na ratunek<\/h3>\n\n\n\nW ci\u0105gu ostatnich 10 lat idea konteneryzacji zyska\u0142a uznanie w bran\u017cy. Naturaln\u0105 decyzj\u0105 by\u0142o wi\u0119c wybranie kontener\u00f3w jako rozwi\u0105zania dla naszej kwestii test\u00f3w integracyjnych. Jest to proste, czyste rozwi\u0105zanie. Wystarczy uruchomi\u0107 kompilacj\u0119 procesu i wszystko dzia\u0142a! Nie mo\u017cesz w to uwierzy\u0107? Sp\u00f3jrz na t\u0119 prost\u0105 konfiguracj\u0119 kompilacji maven:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-compile\n \n up\n \n \n ${projekt<\/a>.basedir}\/docker-compose.yml\n true.\n \n \n \n down\n post-integration-test\n \n down\n \n \n ${project.basedir}\/docker-compose.yml\n true.<\/code><\/pre>\n\n\n\nI docker-compose.yml<\/code> Plik te\u017c wygl\u0105da ca\u0142kiem nie\u017ale!<\/p>\n\n\n\nwersja: \"3.5\"\n\nus\u0142ugi:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: zawsze\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=has\u0142o\n - POSTGRES_DB=miasta\n porty:\n - \"5432:5432\"\n wolumeny:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: zawsze\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: has\u0142o\n porty:\n - \"15050:80\"\n wolumeny:\n - pgadmin_data:\/data\/pgadmin\n\nwolumeny:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nAle czy dostrzegasz tutaj problem?<\/p>\n\n\n\nStatek towarowy, kt\u00f3ry blokuje wszystko<\/h3>\n\n\n\nPowy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
W ci\u0105gu ostatnich 10 lat idea konteneryzacji zyska\u0142a uznanie w bran\u017cy. Naturaln\u0105 decyzj\u0105 by\u0142o wi\u0119c wybranie kontener\u00f3w jako rozwi\u0105zania dla naszej kwestii test\u00f3w integracyjnych. Jest to proste, czyste rozwi\u0105zanie. Wystarczy uruchomi\u0107 kompilacj\u0119 procesu i wszystko dzia\u0142a! Nie mo\u017cesz w to uwierzy\u0107? Sp\u00f3jrz na t\u0119 prost\u0105 konfiguracj\u0119 kompilacji maven:<\/p>\n\n\n\n
com.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-compile\n \n up\n \n \n ${projekt<\/a>.basedir}\/docker-compose.yml\n true.\n \n \n \n down\n post-integration-test\n \n down\n \n \n ${project.basedir}\/docker-compose.yml\n true.<\/code><\/pre>\n\n\n\nI docker-compose.yml<\/code> Plik te\u017c wygl\u0105da ca\u0142kiem nie\u017ale!<\/p>\n\n\n\nwersja: \"3.5\"\n\nus\u0142ugi:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: zawsze\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=has\u0142o\n - POSTGRES_DB=miasta\n porty:\n - \"5432:5432\"\n wolumeny:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: zawsze\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: has\u0142o\n porty:\n - \"15050:80\"\n wolumeny:\n - pgadmin_data:\/data\/pgadmin\n\nwolumeny:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nAle czy dostrzegasz tutaj problem?<\/p>\n\n\n\nStatek towarowy, kt\u00f3ry blokuje wszystko<\/h3>\n\n\n\nPowy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
I docker-compose.yml<\/code> Plik te\u017c wygl\u0105da ca\u0142kiem nie\u017ale!<\/p>\n\n\n\nwersja: \"3.5\"\n\nus\u0142ugi:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: zawsze\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=has\u0142o\n - POSTGRES_DB=miasta\n porty:\n - \"5432:5432\"\n wolumeny:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: zawsze\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: has\u0142o\n porty:\n - \"15050:80\"\n wolumeny:\n - pgadmin_data:\/data\/pgadmin\n\nwolumeny:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nAle czy dostrzegasz tutaj problem?<\/p>\n\n\n\nStatek towarowy, kt\u00f3ry blokuje wszystko<\/h3>\n\n\n\nPowy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
docker-compose.yml<\/code> Plik te\u017c wygl\u0105da ca\u0142kiem nie\u017ale!<\/p>\n\n\n\nwersja: \"3.5\"\n\nus\u0142ugi:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: zawsze\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=has\u0142o\n - POSTGRES_DB=miasta\n porty:\n - \"5432:5432\"\n wolumeny:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: zawsze\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: has\u0142o\n porty:\n - \"15050:80\"\n wolumeny:\n - pgadmin_data:\/data\/pgadmin\n\nwolumeny:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nAle czy dostrzegasz tutaj problem?<\/p>\n\n\n\nStatek towarowy, kt\u00f3ry blokuje wszystko<\/h3>\n\n\n\nPowy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
wersja: \"3.5\"\n\nus\u0142ugi:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: zawsze\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=has\u0142o\n - POSTGRES_DB=miasta\n porty:\n - \"5432:5432\"\n wolumeny:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: zawsze\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: has\u0142o\n porty:\n - \"15050:80\"\n wolumeny:\n - pgadmin_data:\/data\/pgadmin\n\nwolumeny:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nAle czy dostrzegasz tutaj problem?<\/p>\n\n\n\nStatek towarowy, kt\u00f3ry blokuje wszystko<\/h3>\n\n\n\nPowy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
Ale czy dostrzegasz tutaj problem?<\/p>\n\n\n\n
Powy\u017cszy przyk\u0142ad jest bardzo prosty. Tylko jedna baza danych postgres, pgAdmin i to wszystko. Po uruchomieniu<\/p>\n\n\n\n
bash\n$ mvn clean verify\n<\/code>nast\u0119pnie wtyczka maven uruchamia kontenery, a po testach je wy\u0142\u0105cza. Problemy zaczynaj\u0105 si\u0119, gdy projekt si\u0119 rozrasta, a nasz plik compose r\u00f3wnie\u017c ro\u015bnie. Za ka\u017cdym razem trzeba b\u0119dzie uruchamia\u0107 wszystkie kontenery i b\u0119d\u0105 one \u017cy\u0142y przez ca\u0142y czas trwania kompilacji. Mo\u017cna nieco poprawi\u0107 sytuacj\u0119 zmieniaj\u0105c konfiguracj\u0119 wykonywania plugin\u00f3w, ale to nie wystarczy. W najgorszym przypadku kontenery wyczerpi\u0105 zasoby systemowe przed rozpocz\u0119ciem test\u00f3w!<\/p>\n\n\n\nI nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
I nie jest to jedyny problem. Nie mo\u017cna uruchomi\u0107 pojedynczego testu integracyjnego z IDE. Wcze\u015bniej trzeba r\u0119cznie uruchomi\u0107 kontenery. Co wi\u0119cej, nast\u0119pne uruchomienie mavena zburzy te kontenery (sp\u00f3jrz na w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
w d\u00f3\u0142<\/code> wykonanie).<\/p>\n\n\n\nWi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
Wi\u0119c to rozwi\u0105zanie jest jak du\u017cy statek towarowy. Je\u015bli wszystko dzia\u0142a dobrze, to jest w porz\u0105dku. Ka\u017cde nieoczekiwane lub nietypowe zachowanie prowadzi do my<\/a> do jakiej\u015b katastrofy.<\/p>\n\n\n\nKontenery testowe - uruchamianie kontener\u00f3w z test\u00f3w<\/h2>\n\n\n\nAle co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
Ale co by by\u0142o, gdyby\u015bmy mogli uruchamia\u0107 nasze kontenery z test\u00f3w? Ten pomys\u0142 wygl\u0105da dobrze i jest ju\u017c wdra\u017cany. Pojemniki testowe<\/a>Poniewa\u017c m\u00f3wimy o tym projekcie, oto rozwi\u0105zanie naszych problem\u00f3w. Nie jest idealne, ale nikt nie jest idealny.<\/p>\n\n\n\nTo jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
To jest Java<\/a><\/strong> kt\u00f3ra obs\u0142uguje testy JUnit i Spock, zapewniaj\u0105c lekkie i \u0142atwe sposoby uruchamiania Docker<\/a> kontener. Przyjrzyjmy si\u0119 temu i napiszmy troch\u0119 kodu!<\/p>\n\n\n\nWymagania wst\u0119pne i konfiguracja<\/h3>\n\n\n\nZanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
Zanim zaczniemy, musimy sprawdzi\u0107 nasz\u0105 konfiguracj\u0119. Pojemniki testowe<\/strong> potrzeba:<\/p>\n\n\n\n\nDocker w wersji v17.09,<\/li>\n\n\n\nJava w wersji minimum 1.8,<\/li>\n\n\n\nDost\u0119p do sieci, zw\u0142aszcza do docker.hub.<\/li>\n<\/ul>\n\n\n\nWi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
Wi\u0119cej informacji na temat wymaga\u0144 dla okre\u015blonego systemu operacyjnego i CI mo\u017cna znale\u017a\u0107 na stroniew dokumentacja<\/a>.<\/p>\n\n\n\nTeraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
Teraz nadszed\u0142 czas, aby doda\u0107 kilka linii do pom.xml<\/code>.<\/p>\n\n\n\n
pom.xml<\/code>.<\/p>\n\n\n\n