Moderne applikasjonsutvikling er basert p\u00e5 \u00e9n enkel regel:<\/p>\n\n\n\n
\nBruk sammensetning<\/b><\/p>\n<\/blockquote>\n\n\n\nVi setter sammen klasser, funksjoner og tjenester til st\u00f8rre deler av programvaren. Det siste elementet er grunnlaget for mikrotjenester<\/a> og sekskantet arkitektur<\/a>. Vi \u00f8nsker \u00e5 bruke eksisterende l\u00f8sninger, integrere dem med programvaren v\u00e5r og g\u00e5 rett p\u00e5 marked<\/a>.<\/p>\n\n\n\n\u00d8nsker du \u00e5 h\u00e5ndtere kontoregistrering og lagre bruker data<\/a>? Du kan velge en av OAuth-tjenestene. Kanskje applikasjonen din tilbyr en form for abonnement eller betaling? Det finnes mange tjenester som kan hjelpe deg med \u00e5 h\u00e5ndtere dette. Trenger du noen analyser p\u00e5 nettstedet ditt, men forst\u00e5r ikke GDPR<\/a>? Ta gjerne en av de ferdige l\u00f8sningene.<\/p>\n\n\n\nNoe som gj\u00f8r utvikling s\u00e5 enkelt fra et forretningsmessig synspunkt, kan gi deg hodepine - n\u00e5r du skal skrive en enkel test.<\/p>\n\n\n\nDe fantastiske dyrene: K\u00f8er, databaser og hvordan du tester dem<\/h2>\n\n\n\nEnhetstesting er ganske enkelt. Hvis du bare f\u00f8lger reglene, vil testmilj\u00f8et ditt og kode<\/a> er sunne. Hvilke regler er det?<\/p>\n\n\n\n\nLett \u00e5 skrive<\/b> - en enhetstest skal v\u00e6re enkel \u00e5 skrive fordi du skriver mange av dem. Mindre innsats betyr at det skrives flere tester.<\/li>\n\n\n\nLesbar<\/b> - testkoden skal v\u00e6re lett \u00e5 lese. Testen er en historie. Den beskriver hvordan programvaren oppf\u00f8rer seg, og kan brukes som en snarvei til dokumentasjon. En god enhetstest hjelper deg med \u00e5 fikse feil uten \u00e5 feils\u00f8ke koden.<\/li>\n\n\n\nP\u00e5litelig<\/b> - testen skal bare feile hvis det er en feil i systemet som testes. Er det \u00e5penbart? Ikke alltid. Noen ganger best\u00e5r tester hvis du kj\u00f8rer dem \u00e9n og \u00e9n, men feiler n\u00e5r du kj\u00f8rer dem som et sett. De best\u00e5r p\u00e5 din maskin, men feiler p\u00e5 CI (Fungerer p\u00e5 min maskin<\/a>). En god enhetstest har bare \u00e9n \u00e5rsak til feil.<\/li>\n\n\n\nRask<\/b> - testene skal v\u00e6re raske. Forberedelse til kj\u00f8ring, start og selve testutf\u00f8relsen b\u00f8r g\u00e5 sv\u00e6rt raskt. Ellers vil du skrive dem, men ikke kj\u00f8re dem. Sakte tester betyr tapt fokus. Du venter og ser p\u00e5 fremdriftslinjen.<\/li>\n\n\n\nUavhengig<\/b> - Til slutt skal testen v\u00e6re uavhengig. Denne regelen stammer fra de foreg\u00e5ende. Bare virkelig uavhengige tester kan bli en enhet. De forstyrrer ikke hverandre, kan kj\u00f8res i hvilken som helst rekkef\u00f8lge, og potensielle feil avhenger ikke av resultatene fra andre tester. Uavhengige betyr ogs\u00e5 at de ikke er avhengige av eksterne ressurser som databaser, meldingstjenester eller filsystem. Hvis du trenger \u00e5 kommunisere med eksterne ressurser, kan du bruke mocks, stubber eller dummies.<\/li>\n<\/ul>\n\n\n\nAlt blir komplisert n\u00e5r vi \u00f8nsker \u00e5 skrive noen integrasjonstester. Det er ikke s\u00e5 ille hvis vi \u00f8nsker \u00e5 teste noen f\u00e5 tjenester sammen. Men n\u00e5r vi skal teste tjenester som bruker eksterne ressurser, som databaser eller meldingstjenester, er vi ute p\u00e5 dypt vann.<\/p>\n\n\n\nFor \u00e5 kj\u00f8re testen m\u00e5 du installere...<\/h3>\n\n\n\nFor mange \u00e5r siden, da vi \u00f8nsket \u00e5 lage integrasjonstester og bruke f.eks. databaser, hadde vi to alternativer:<\/p>\n\n\n\n\nVi kan installere en database lokalt. Sett opp et skjema og koble til fra testen v\u00e5r;<\/li>\n\n\n\nVi kan koble oss til en eksisterende instans \"et sted i verdensrommet\".<\/li>\n<\/ol>\n\n\n\nBegge hadde fordeler, begge hadde ulemper. Men begge introduserer flere niv\u00e5er av kompleksitet. Noen ganger var det teknisk kompleksitet som f\u00f8lge av egenskapene til visse verkt\u00f8y, f.eks. installasjon og administrasjon av Oracle DB p\u00e5 din lokale host. Noen ganger var det en ulempe i prosessen, f.eks. at du m\u00e5 bli enig med test team<\/a> om JMS-bruk hver gang du vil kj\u00f8re tester.<\/p>\n\n\n\nContainere til unnsetning<\/h3>\n\n\n\nI l\u00f8pet av de siste ti \u00e5rene har ideen om containerisering blitt anerkjent i bransjen. Derfor var det naturlig \u00e5 velge containere som l\u00f8sning p\u00e5 integrasjonstestproblemet v\u00e5rt. Dette er en enkel og ren l\u00f8sning. Du kj\u00f8rer bare prosessbyggingen, s\u00e5 fungerer alt! Kan du ikke tro det? Ta en titt p\u00e5 denne enkle konfigurasjonen av en maven-build:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-kompilere\n \n opp\n \n \n ${prosjekt<\/a>.basedir}\/docker-compose.yml.\n true\n \n \n \n down\n post-integrasjonstest\n \n ned\n \n \n ${project.basedir}\/docker-compose.yml true\n true<\/code><\/pre>\n\n\n\nOg docker-compose.yml<\/code> filen ser ogs\u00e5 ganske fin ut!<\/p>\n\n\n\nversjon: \"3.5\"\n\ntjenester:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: alltid\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=passord\n - POSTGRES_DB=byer\n ports:\n - \"5432:5432\"\n volumes:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: alltid\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: password\n ports:\n - \"15050:80\"\n volumer\n - pgadmin_data:\/data\/pgadmin\n\nvolumes:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nMen kan du se problemet her?<\/p>\n\n\n\nEt lasteskip som blokkerer alt<\/h3>\n\n\n\nEksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
Bruk sammensetning<\/b><\/p>\n<\/blockquote>\n\n\n\n
Vi setter sammen klasser, funksjoner og tjenester til st\u00f8rre deler av programvaren. Det siste elementet er grunnlaget for mikrotjenester<\/a> og sekskantet arkitektur<\/a>. Vi \u00f8nsker \u00e5 bruke eksisterende l\u00f8sninger, integrere dem med programvaren v\u00e5r og g\u00e5 rett p\u00e5 marked<\/a>.<\/p>\n\n\n\n\u00d8nsker du \u00e5 h\u00e5ndtere kontoregistrering og lagre bruker data<\/a>? Du kan velge en av OAuth-tjenestene. Kanskje applikasjonen din tilbyr en form for abonnement eller betaling? Det finnes mange tjenester som kan hjelpe deg med \u00e5 h\u00e5ndtere dette. Trenger du noen analyser p\u00e5 nettstedet ditt, men forst\u00e5r ikke GDPR<\/a>? Ta gjerne en av de ferdige l\u00f8sningene.<\/p>\n\n\n\nNoe som gj\u00f8r utvikling s\u00e5 enkelt fra et forretningsmessig synspunkt, kan gi deg hodepine - n\u00e5r du skal skrive en enkel test.<\/p>\n\n\n\nDe fantastiske dyrene: K\u00f8er, databaser og hvordan du tester dem<\/h2>\n\n\n\nEnhetstesting er ganske enkelt. Hvis du bare f\u00f8lger reglene, vil testmilj\u00f8et ditt og kode<\/a> er sunne. Hvilke regler er det?<\/p>\n\n\n\n\nLett \u00e5 skrive<\/b> - en enhetstest skal v\u00e6re enkel \u00e5 skrive fordi du skriver mange av dem. Mindre innsats betyr at det skrives flere tester.<\/li>\n\n\n\nLesbar<\/b> - testkoden skal v\u00e6re lett \u00e5 lese. Testen er en historie. Den beskriver hvordan programvaren oppf\u00f8rer seg, og kan brukes som en snarvei til dokumentasjon. En god enhetstest hjelper deg med \u00e5 fikse feil uten \u00e5 feils\u00f8ke koden.<\/li>\n\n\n\nP\u00e5litelig<\/b> - testen skal bare feile hvis det er en feil i systemet som testes. Er det \u00e5penbart? Ikke alltid. Noen ganger best\u00e5r tester hvis du kj\u00f8rer dem \u00e9n og \u00e9n, men feiler n\u00e5r du kj\u00f8rer dem som et sett. De best\u00e5r p\u00e5 din maskin, men feiler p\u00e5 CI (Fungerer p\u00e5 min maskin<\/a>). En god enhetstest har bare \u00e9n \u00e5rsak til feil.<\/li>\n\n\n\nRask<\/b> - testene skal v\u00e6re raske. Forberedelse til kj\u00f8ring, start og selve testutf\u00f8relsen b\u00f8r g\u00e5 sv\u00e6rt raskt. Ellers vil du skrive dem, men ikke kj\u00f8re dem. Sakte tester betyr tapt fokus. Du venter og ser p\u00e5 fremdriftslinjen.<\/li>\n\n\n\nUavhengig<\/b> - Til slutt skal testen v\u00e6re uavhengig. Denne regelen stammer fra de foreg\u00e5ende. Bare virkelig uavhengige tester kan bli en enhet. De forstyrrer ikke hverandre, kan kj\u00f8res i hvilken som helst rekkef\u00f8lge, og potensielle feil avhenger ikke av resultatene fra andre tester. Uavhengige betyr ogs\u00e5 at de ikke er avhengige av eksterne ressurser som databaser, meldingstjenester eller filsystem. Hvis du trenger \u00e5 kommunisere med eksterne ressurser, kan du bruke mocks, stubber eller dummies.<\/li>\n<\/ul>\n\n\n\nAlt blir komplisert n\u00e5r vi \u00f8nsker \u00e5 skrive noen integrasjonstester. Det er ikke s\u00e5 ille hvis vi \u00f8nsker \u00e5 teste noen f\u00e5 tjenester sammen. Men n\u00e5r vi skal teste tjenester som bruker eksterne ressurser, som databaser eller meldingstjenester, er vi ute p\u00e5 dypt vann.<\/p>\n\n\n\nFor \u00e5 kj\u00f8re testen m\u00e5 du installere...<\/h3>\n\n\n\nFor mange \u00e5r siden, da vi \u00f8nsket \u00e5 lage integrasjonstester og bruke f.eks. databaser, hadde vi to alternativer:<\/p>\n\n\n\n\nVi kan installere en database lokalt. Sett opp et skjema og koble til fra testen v\u00e5r;<\/li>\n\n\n\nVi kan koble oss til en eksisterende instans \"et sted i verdensrommet\".<\/li>\n<\/ol>\n\n\n\nBegge hadde fordeler, begge hadde ulemper. Men begge introduserer flere niv\u00e5er av kompleksitet. Noen ganger var det teknisk kompleksitet som f\u00f8lge av egenskapene til visse verkt\u00f8y, f.eks. installasjon og administrasjon av Oracle DB p\u00e5 din lokale host. Noen ganger var det en ulempe i prosessen, f.eks. at du m\u00e5 bli enig med test team<\/a> om JMS-bruk hver gang du vil kj\u00f8re tester.<\/p>\n\n\n\nContainere til unnsetning<\/h3>\n\n\n\nI l\u00f8pet av de siste ti \u00e5rene har ideen om containerisering blitt anerkjent i bransjen. Derfor var det naturlig \u00e5 velge containere som l\u00f8sning p\u00e5 integrasjonstestproblemet v\u00e5rt. Dette er en enkel og ren l\u00f8sning. Du kj\u00f8rer bare prosessbyggingen, s\u00e5 fungerer alt! Kan du ikke tro det? Ta en titt p\u00e5 denne enkle konfigurasjonen av en maven-build:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-kompilere\n \n opp\n \n \n ${prosjekt<\/a>.basedir}\/docker-compose.yml.\n true\n \n \n \n down\n post-integrasjonstest\n \n ned\n \n \n ${project.basedir}\/docker-compose.yml true\n true<\/code><\/pre>\n\n\n\nOg docker-compose.yml<\/code> filen ser ogs\u00e5 ganske fin ut!<\/p>\n\n\n\nversjon: \"3.5\"\n\ntjenester:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: alltid\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=passord\n - POSTGRES_DB=byer\n ports:\n - \"5432:5432\"\n volumes:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: alltid\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: password\n ports:\n - \"15050:80\"\n volumer\n - pgadmin_data:\/data\/pgadmin\n\nvolumes:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nMen kan du se problemet her?<\/p>\n\n\n\nEt lasteskip som blokkerer alt<\/h3>\n\n\n\nEksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
\u00d8nsker du \u00e5 h\u00e5ndtere kontoregistrering og lagre bruker data<\/a>? Du kan velge en av OAuth-tjenestene. Kanskje applikasjonen din tilbyr en form for abonnement eller betaling? Det finnes mange tjenester som kan hjelpe deg med \u00e5 h\u00e5ndtere dette. Trenger du noen analyser p\u00e5 nettstedet ditt, men forst\u00e5r ikke GDPR<\/a>? Ta gjerne en av de ferdige l\u00f8sningene.<\/p>\n\n\n\nNoe som gj\u00f8r utvikling s\u00e5 enkelt fra et forretningsmessig synspunkt, kan gi deg hodepine - n\u00e5r du skal skrive en enkel test.<\/p>\n\n\n\nDe fantastiske dyrene: K\u00f8er, databaser og hvordan du tester dem<\/h2>\n\n\n\nEnhetstesting er ganske enkelt. Hvis du bare f\u00f8lger reglene, vil testmilj\u00f8et ditt og kode<\/a> er sunne. Hvilke regler er det?<\/p>\n\n\n\n\nLett \u00e5 skrive<\/b> - en enhetstest skal v\u00e6re enkel \u00e5 skrive fordi du skriver mange av dem. Mindre innsats betyr at det skrives flere tester.<\/li>\n\n\n\nLesbar<\/b> - testkoden skal v\u00e6re lett \u00e5 lese. Testen er en historie. Den beskriver hvordan programvaren oppf\u00f8rer seg, og kan brukes som en snarvei til dokumentasjon. En god enhetstest hjelper deg med \u00e5 fikse feil uten \u00e5 feils\u00f8ke koden.<\/li>\n\n\n\nP\u00e5litelig<\/b> - testen skal bare feile hvis det er en feil i systemet som testes. Er det \u00e5penbart? Ikke alltid. Noen ganger best\u00e5r tester hvis du kj\u00f8rer dem \u00e9n og \u00e9n, men feiler n\u00e5r du kj\u00f8rer dem som et sett. De best\u00e5r p\u00e5 din maskin, men feiler p\u00e5 CI (Fungerer p\u00e5 min maskin<\/a>). En god enhetstest har bare \u00e9n \u00e5rsak til feil.<\/li>\n\n\n\nRask<\/b> - testene skal v\u00e6re raske. Forberedelse til kj\u00f8ring, start og selve testutf\u00f8relsen b\u00f8r g\u00e5 sv\u00e6rt raskt. Ellers vil du skrive dem, men ikke kj\u00f8re dem. Sakte tester betyr tapt fokus. Du venter og ser p\u00e5 fremdriftslinjen.<\/li>\n\n\n\nUavhengig<\/b> - Til slutt skal testen v\u00e6re uavhengig. Denne regelen stammer fra de foreg\u00e5ende. Bare virkelig uavhengige tester kan bli en enhet. De forstyrrer ikke hverandre, kan kj\u00f8res i hvilken som helst rekkef\u00f8lge, og potensielle feil avhenger ikke av resultatene fra andre tester. Uavhengige betyr ogs\u00e5 at de ikke er avhengige av eksterne ressurser som databaser, meldingstjenester eller filsystem. Hvis du trenger \u00e5 kommunisere med eksterne ressurser, kan du bruke mocks, stubber eller dummies.<\/li>\n<\/ul>\n\n\n\nAlt blir komplisert n\u00e5r vi \u00f8nsker \u00e5 skrive noen integrasjonstester. Det er ikke s\u00e5 ille hvis vi \u00f8nsker \u00e5 teste noen f\u00e5 tjenester sammen. Men n\u00e5r vi skal teste tjenester som bruker eksterne ressurser, som databaser eller meldingstjenester, er vi ute p\u00e5 dypt vann.<\/p>\n\n\n\nFor \u00e5 kj\u00f8re testen m\u00e5 du installere...<\/h3>\n\n\n\nFor mange \u00e5r siden, da vi \u00f8nsket \u00e5 lage integrasjonstester og bruke f.eks. databaser, hadde vi to alternativer:<\/p>\n\n\n\n\nVi kan installere en database lokalt. Sett opp et skjema og koble til fra testen v\u00e5r;<\/li>\n\n\n\nVi kan koble oss til en eksisterende instans \"et sted i verdensrommet\".<\/li>\n<\/ol>\n\n\n\nBegge hadde fordeler, begge hadde ulemper. Men begge introduserer flere niv\u00e5er av kompleksitet. Noen ganger var det teknisk kompleksitet som f\u00f8lge av egenskapene til visse verkt\u00f8y, f.eks. installasjon og administrasjon av Oracle DB p\u00e5 din lokale host. Noen ganger var det en ulempe i prosessen, f.eks. at du m\u00e5 bli enig med test team<\/a> om JMS-bruk hver gang du vil kj\u00f8re tester.<\/p>\n\n\n\nContainere til unnsetning<\/h3>\n\n\n\nI l\u00f8pet av de siste ti \u00e5rene har ideen om containerisering blitt anerkjent i bransjen. Derfor var det naturlig \u00e5 velge containere som l\u00f8sning p\u00e5 integrasjonstestproblemet v\u00e5rt. Dette er en enkel og ren l\u00f8sning. Du kj\u00f8rer bare prosessbyggingen, s\u00e5 fungerer alt! Kan du ikke tro det? Ta en titt p\u00e5 denne enkle konfigurasjonen av en maven-build:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-kompilere\n \n opp\n \n \n ${prosjekt<\/a>.basedir}\/docker-compose.yml.\n true\n \n \n \n down\n post-integrasjonstest\n \n ned\n \n \n ${project.basedir}\/docker-compose.yml true\n true<\/code><\/pre>\n\n\n\nOg docker-compose.yml<\/code> filen ser ogs\u00e5 ganske fin ut!<\/p>\n\n\n\nversjon: \"3.5\"\n\ntjenester:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: alltid\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=passord\n - POSTGRES_DB=byer\n ports:\n - \"5432:5432\"\n volumes:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: alltid\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: password\n ports:\n - \"15050:80\"\n volumer\n - pgadmin_data:\/data\/pgadmin\n\nvolumes:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nMen kan du se problemet her?<\/p>\n\n\n\nEt lasteskip som blokkerer alt<\/h3>\n\n\n\nEksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
Noe som gj\u00f8r utvikling s\u00e5 enkelt fra et forretningsmessig synspunkt, kan gi deg hodepine - n\u00e5r du skal skrive en enkel test.<\/p>\n\n\n\n
Enhetstesting er ganske enkelt. Hvis du bare f\u00f8lger reglene, vil testmilj\u00f8et ditt og kode<\/a> er sunne. Hvilke regler er det?<\/p>\n\n\n\n\nLett \u00e5 skrive<\/b> - en enhetstest skal v\u00e6re enkel \u00e5 skrive fordi du skriver mange av dem. Mindre innsats betyr at det skrives flere tester.<\/li>\n\n\n\nLesbar<\/b> - testkoden skal v\u00e6re lett \u00e5 lese. Testen er en historie. Den beskriver hvordan programvaren oppf\u00f8rer seg, og kan brukes som en snarvei til dokumentasjon. En god enhetstest hjelper deg med \u00e5 fikse feil uten \u00e5 feils\u00f8ke koden.<\/li>\n\n\n\nP\u00e5litelig<\/b> - testen skal bare feile hvis det er en feil i systemet som testes. Er det \u00e5penbart? Ikke alltid. Noen ganger best\u00e5r tester hvis du kj\u00f8rer dem \u00e9n og \u00e9n, men feiler n\u00e5r du kj\u00f8rer dem som et sett. De best\u00e5r p\u00e5 din maskin, men feiler p\u00e5 CI (Fungerer p\u00e5 min maskin<\/a>). En god enhetstest har bare \u00e9n \u00e5rsak til feil.<\/li>\n\n\n\nRask<\/b> - testene skal v\u00e6re raske. Forberedelse til kj\u00f8ring, start og selve testutf\u00f8relsen b\u00f8r g\u00e5 sv\u00e6rt raskt. Ellers vil du skrive dem, men ikke kj\u00f8re dem. Sakte tester betyr tapt fokus. Du venter og ser p\u00e5 fremdriftslinjen.<\/li>\n\n\n\nUavhengig<\/b> - Til slutt skal testen v\u00e6re uavhengig. Denne regelen stammer fra de foreg\u00e5ende. Bare virkelig uavhengige tester kan bli en enhet. De forstyrrer ikke hverandre, kan kj\u00f8res i hvilken som helst rekkef\u00f8lge, og potensielle feil avhenger ikke av resultatene fra andre tester. Uavhengige betyr ogs\u00e5 at de ikke er avhengige av eksterne ressurser som databaser, meldingstjenester eller filsystem. Hvis du trenger \u00e5 kommunisere med eksterne ressurser, kan du bruke mocks, stubber eller dummies.<\/li>\n<\/ul>\n\n\n\nAlt blir komplisert n\u00e5r vi \u00f8nsker \u00e5 skrive noen integrasjonstester. Det er ikke s\u00e5 ille hvis vi \u00f8nsker \u00e5 teste noen f\u00e5 tjenester sammen. Men n\u00e5r vi skal teste tjenester som bruker eksterne ressurser, som databaser eller meldingstjenester, er vi ute p\u00e5 dypt vann.<\/p>\n\n\n\nFor \u00e5 kj\u00f8re testen m\u00e5 du installere...<\/h3>\n\n\n\nFor mange \u00e5r siden, da vi \u00f8nsket \u00e5 lage integrasjonstester og bruke f.eks. databaser, hadde vi to alternativer:<\/p>\n\n\n\n\nVi kan installere en database lokalt. Sett opp et skjema og koble til fra testen v\u00e5r;<\/li>\n\n\n\nVi kan koble oss til en eksisterende instans \"et sted i verdensrommet\".<\/li>\n<\/ol>\n\n\n\nBegge hadde fordeler, begge hadde ulemper. Men begge introduserer flere niv\u00e5er av kompleksitet. Noen ganger var det teknisk kompleksitet som f\u00f8lge av egenskapene til visse verkt\u00f8y, f.eks. installasjon og administrasjon av Oracle DB p\u00e5 din lokale host. Noen ganger var det en ulempe i prosessen, f.eks. at du m\u00e5 bli enig med test team<\/a> om JMS-bruk hver gang du vil kj\u00f8re tester.<\/p>\n\n\n\nContainere til unnsetning<\/h3>\n\n\n\nI l\u00f8pet av de siste ti \u00e5rene har ideen om containerisering blitt anerkjent i bransjen. Derfor var det naturlig \u00e5 velge containere som l\u00f8sning p\u00e5 integrasjonstestproblemet v\u00e5rt. Dette er en enkel og ren l\u00f8sning. Du kj\u00f8rer bare prosessbyggingen, s\u00e5 fungerer alt! Kan du ikke tro det? Ta en titt p\u00e5 denne enkle konfigurasjonen av en maven-build:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-kompilere\n \n opp\n \n \n ${prosjekt<\/a>.basedir}\/docker-compose.yml.\n true\n \n \n \n down\n post-integrasjonstest\n \n ned\n \n \n ${project.basedir}\/docker-compose.yml true\n true<\/code><\/pre>\n\n\n\nOg docker-compose.yml<\/code> filen ser ogs\u00e5 ganske fin ut!<\/p>\n\n\n\nversjon: \"3.5\"\n\ntjenester:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: alltid\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=passord\n - POSTGRES_DB=byer\n ports:\n - \"5432:5432\"\n volumes:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: alltid\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: password\n ports:\n - \"15050:80\"\n volumer\n - pgadmin_data:\/data\/pgadmin\n\nvolumes:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nMen kan du se problemet her?<\/p>\n\n\n\nEt lasteskip som blokkerer alt<\/h3>\n\n\n\nEksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
Alt blir komplisert n\u00e5r vi \u00f8nsker \u00e5 skrive noen integrasjonstester. Det er ikke s\u00e5 ille hvis vi \u00f8nsker \u00e5 teste noen f\u00e5 tjenester sammen. Men n\u00e5r vi skal teste tjenester som bruker eksterne ressurser, som databaser eller meldingstjenester, er vi ute p\u00e5 dypt vann.<\/p>\n\n\n\n
For mange \u00e5r siden, da vi \u00f8nsket \u00e5 lage integrasjonstester og bruke f.eks. databaser, hadde vi to alternativer:<\/p>\n\n\n\n
Begge hadde fordeler, begge hadde ulemper. Men begge introduserer flere niv\u00e5er av kompleksitet. Noen ganger var det teknisk kompleksitet som f\u00f8lge av egenskapene til visse verkt\u00f8y, f.eks. installasjon og administrasjon av Oracle DB p\u00e5 din lokale host. Noen ganger var det en ulempe i prosessen, f.eks. at du m\u00e5 bli enig med test team<\/a> om JMS-bruk hver gang du vil kj\u00f8re tester.<\/p>\n\n\n\nContainere til unnsetning<\/h3>\n\n\n\nI l\u00f8pet av de siste ti \u00e5rene har ideen om containerisering blitt anerkjent i bransjen. Derfor var det naturlig \u00e5 velge containere som l\u00f8sning p\u00e5 integrasjonstestproblemet v\u00e5rt. Dette er en enkel og ren l\u00f8sning. Du kj\u00f8rer bare prosessbyggingen, s\u00e5 fungerer alt! Kan du ikke tro det? Ta en titt p\u00e5 denne enkle konfigurasjonen av en maven-build:<\/p>\n\n\n\ncom.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-kompilere\n \n opp\n \n \n ${prosjekt<\/a>.basedir}\/docker-compose.yml.\n true\n \n \n \n down\n post-integrasjonstest\n \n ned\n \n \n ${project.basedir}\/docker-compose.yml true\n true<\/code><\/pre>\n\n\n\nOg docker-compose.yml<\/code> filen ser ogs\u00e5 ganske fin ut!<\/p>\n\n\n\nversjon: \"3.5\"\n\ntjenester:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: alltid\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=passord\n - POSTGRES_DB=byer\n ports:\n - \"5432:5432\"\n volumes:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: alltid\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: password\n ports:\n - \"15050:80\"\n volumer\n - pgadmin_data:\/data\/pgadmin\n\nvolumes:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nMen kan du se problemet her?<\/p>\n\n\n\nEt lasteskip som blokkerer alt<\/h3>\n\n\n\nEksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
I l\u00f8pet av de siste ti \u00e5rene har ideen om containerisering blitt anerkjent i bransjen. Derfor var det naturlig \u00e5 velge containere som l\u00f8sning p\u00e5 integrasjonstestproblemet v\u00e5rt. Dette er en enkel og ren l\u00f8sning. Du kj\u00f8rer bare prosessbyggingen, s\u00e5 fungerer alt! Kan du ikke tro det? Ta en titt p\u00e5 denne enkle konfigurasjonen av en maven-build:<\/p>\n\n\n\n
com.dkanejs.maven.plugins\n docker-compose-maven-plugin\n 4.0.0\n \n \n up\n test-kompilere\n \n opp\n \n \n ${prosjekt<\/a>.basedir}\/docker-compose.yml.\n true\n \n \n \n down\n post-integrasjonstest\n \n ned\n \n \n ${project.basedir}\/docker-compose.yml true\n true<\/code><\/pre>\n\n\n\nOg docker-compose.yml<\/code> filen ser ogs\u00e5 ganske fin ut!<\/p>\n\n\n\nversjon: \"3.5\"\n\ntjenester:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: alltid\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=passord\n - POSTGRES_DB=byer\n ports:\n - \"5432:5432\"\n volumes:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: alltid\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: password\n ports:\n - \"15050:80\"\n volumer\n - pgadmin_data:\/data\/pgadmin\n\nvolumes:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nMen kan du se problemet her?<\/p>\n\n\n\nEt lasteskip som blokkerer alt<\/h3>\n\n\n\nEksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
Og docker-compose.yml<\/code> filen ser ogs\u00e5 ganske fin ut!<\/p>\n\n\n\nversjon: \"3.5\"\n\ntjenester:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: alltid\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=passord\n - POSTGRES_DB=byer\n ports:\n - \"5432:5432\"\n volumes:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: alltid\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: password\n ports:\n - \"15050:80\"\n volumer\n - pgadmin_data:\/data\/pgadmin\n\nvolumes:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nMen kan du se problemet her?<\/p>\n\n\n\nEt lasteskip som blokkerer alt<\/h3>\n\n\n\nEksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
docker-compose.yml<\/code> filen ser ogs\u00e5 ganske fin ut!<\/p>\n\n\n\nversjon: \"3.5\"\n\ntjenester:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: alltid\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=passord\n - POSTGRES_DB=byer\n ports:\n - \"5432:5432\"\n volumes:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: alltid\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: password\n ports:\n - \"15050:80\"\n volumer\n - pgadmin_data:\/data\/pgadmin\n\nvolumes:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nMen kan du se problemet her?<\/p>\n\n\n\nEt lasteskip som blokkerer alt<\/h3>\n\n\n\nEksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
versjon: \"3.5\"\n\ntjenester:\n\n postgres:\n container_name: reactivedb\n image: postgres:13.2\n restart: alltid\n environment:\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=passord\n - POSTGRES_DB=byer\n ports:\n - \"5432:5432\"\n volumes:\n - postgres_data:\/data\/db\n\n pgadmin:\n container_name: pgadmin4\n image: dpage\/pgadmin4\n restart: alltid\n environment:\n PGADMIN_DEFAULT_EMAIL: admin@admin.com\n PGADMIN_DEFAULT_PASSWORD: password\n ports:\n - \"15050:80\"\n volumer\n - pgadmin_data:\/data\/pgadmin\n\nvolumes:\n postgres_data:\n pgadmin_data:<\/code><\/pre>\n\n\n\nMen kan du se problemet her?<\/p>\n\n\n\nEt lasteskip som blokkerer alt<\/h3>\n\n\n\nEksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\nbash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
Men kan du se problemet her?<\/p>\n\n\n\n
Eksemplet ovenfor er veldig enkelt. Bare \u00e9n postgres-database, pgAdmin og det er alt. N\u00e5r du kj\u00f8rer<\/p>\n\n\n\n
bash\n$ mvn clean verify\n<\/code>s\u00e5 starter maven-plugin-modulen containerne og sl\u00e5r dem av etter testene. Problemene oppst\u00e5r n\u00e5r prosjektet vokser, og Compose-filen v\u00e5r ogs\u00e5 vokser. Hver gang m\u00e5 du starte alle containerne, og de vil v\u00e6re i live gjennom hele byggingen. Du kan gj\u00f8re situasjonen litt bedre ved \u00e5 endre konfigurasjonen for kj\u00f8ring av plugin-modulen, men det er ikke nok. I verste fall bruker containerne opp systemressursene dine f\u00f8r testene starter!<\/p>\n\n\n\nOg dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
Og dette er ikke det eneste problemet. Du kan ikke kj\u00f8re en eneste integrasjonstest fra IDE-en din. F\u00f8r det m\u00e5 du starte containerne for h\u00e5nd. Dessuten vil neste maven-kj\u00f8ring rive ned disse containerne (ta en titt p\u00e5 ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
ned<\/code> utf\u00f8relse).<\/p>\n\n\n\nS\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
S\u00e5 denne l\u00f8sningen er som et stort lasteskip. Hvis alt fungerer som det skal, er alt i orden. Enhver uventet eller uvanlig oppf\u00f8rsel f\u00f8rer til oss<\/a> til en slags katastrofe.<\/p>\n\n\n\nTestcontainere - kj\u00f8r containere fra tester<\/h2>\n\n\n\nMen hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
Men hva om vi kunne kj\u00f8re containerne v\u00e5re fra tester? Denne ideen ser god ut, og den er allerede i ferd med \u00e5 bli implementert. Testcontainere<\/a>Siden vi snakker om dette prosjektet, her er en l\u00f8sning p\u00e5 problemene v\u00e5re. Ikke ideelt, men ingen er perfekt.<\/p>\n\n\n\nDette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
Dette er en Java<\/a><\/strong> som st\u00f8tter JUnit- og Spock-tester, noe som gir lette og enkle m\u00e5ter \u00e5 kj\u00f8re Docker<\/a> container. La oss ta en titt p\u00e5 den og skrive litt kode!<\/p>\n\n\n\nForutsetninger og konfigurasjon<\/h3>\n\n\n\nF\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
F\u00f8r vi begynner, m\u00e5 vi sjekke konfigurasjonen v\u00e5r. Testbeholdere<\/strong> behov:<\/p>\n\n\n\n\nDocker i versjon v17.09,<\/li>\n\n\n\nJava minimum versjon 1.8,<\/li>\n\n\n\nTilgang til nettverk, spesielt til docker.hub.<\/li>\n<\/ul>\n\n\n\nMer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
Mer om kravene til spesifikke operativsystemer og CI finner du heri dokumentasjon<\/a>.<\/p>\n\n\n\nN\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
N\u00e5 er det p\u00e5 tide \u00e5 legge til noen linjer til pom.xml<\/code>.<\/p>\n\n\n\n
pom.xml<\/code>.<\/p>\n\n\n\n