Mockování emailové komunikace v integračních testech

Na projektu JdemeNaTo jsme narazili na problém, jak v selenium integračních testech pracovat s emaily.

Testovaná aplikace posílá emaily přes SMTP protokol. Test je pak musí přečíst a zpracovat. Samozřejmě, že email jako takový se nesmí dostat ven z integračního prostředí.

Poměrně dlouhou dobu jsme používali jednoduché řešení Dumbster. To spočívalo v tom, že si test vytvořil při svém spuštění mock SMTP server na dohodnutém portu, a test si pak přímo přečetl příchozí mail. Po skončení testu se port zase uzavřel.

Toto řešení jsme museli ale opustit v době, kdy máme celé integrační prostředí postavené na dockeru. Testy pouštíme stále pomocí mavenu na TeamCity proti testovanému serveru hostovaném v docker kontejneru. Každý docker kontejner má svoji ip adresu a namá ponětí o tom, kdo ho volá.

Hledali jsme vhodnou náhradu za Dumbster a našli jsme překvapivě robustní implementaci v javě GreenMail, který je určený právě pro testovací účely. Sympatická je i velká variabilita nasazení - poskytují docker image, tak i standalone aplikaci či jako war do Tomcatu. Na straně posílání mailů jsme nemuseli udělat žádnou úpravu. Na straně čtení jsme si napsali jednoduchou rutinu založenou na POP3 protokolu.

Pokud hledáte řešení, jak mockovat email server v interačních testech, mohu GreenMail určitě doporučit.

Code coverage of Selenium tests in TeamCity

There are couples of tools, which measure code coverage in java - cobertura, emma, jacoco.
They work pretty well for regular unit tests.

But how to measure code coverage of integration tests?

Here is my solution

All integration tests are written in Java - jUnit and Selenium WebDriver API - run by standard maven-failsafe-plugin. Application is deployed on Tomcat by TeamCity. Integration tests are run by TeamCity also.

If you run Tomcat with JaCoCo agent, you can measure code coverage on the Tomcat side.

This is part of Tomcat setenv.sh file

CATALINA_OPTS="-Xms512m -Xmx8g -XX:MaxPermSize=1024m -server -javaagent:/opt/tomcat1/org.jacoco.agent-0.7.2.201409121644-runtime.jar=output=tcpserver,address=localhost,port=6300"

After run all integration tests may TeamCity ask for results by jacoco-maven-plugin. It connects to Tomcat by TCP and saves result localy to jaacoco.exec file.

mvn jacoco:dump

TeamCity supports import javacoco result file by service massages. I added a regular command line build step. Service message should be printed into a standard output stream of the build; hence I used linux echo command. Unfortunately, single quote must by surround by double quote.

echo \##teamcity[jacocoReport dataPath="'"target/jacoco.exec"'" includes="'"com.jpower8.*"'" excludes="'"com.jpower8.*.*Test"'"]

Additional tab with coverage results appears in build detail.

Continuous delivery v jPower8

Náš produkt nasazujeme produkci každé dva týdny. Máme tak nastavený sprint cyklus.

 Celý proces je (skoro) plně automatický.


Zdrojáky verzujeme v svn (migraci na git plánujeme).

Stabilitu buildu udržuje TeamCity, které

• provádí unit testy,
• spouští seleniové (integrační) testy,
• nasazuje na testovací prostředí a
• provádí statickou analýzu kódu.

Doba od commitu do nasazení na test je cca 15 minut.

Pro upečení stabilního verze používáme maven-release-plugin, který se postará o to, že zvedne verzi ve všech pomech, otaguje verzi v svn a uloží upečený build do artifactory. To vše se děje jedním stiskem tlačítka na TeamCity.

Posledním krokem je samotné nasazení waru na produkční prostředí. To dělám kvůli svému pocitu důležitosti ještě stále ručně (a protože nechci, aby TeamCity mělo na produkci přístup).

Samostatnou kapitolou je aplikace migračního databázového skriptu. Ještě donedávna jsme ji prováděli ručně, což sebou neslo riziko lidské chyby a hlavně velkého opruzu.

Pokud je například potřeba přejmenovat sloupec do tabulky, přidat index, změnit constraint, vývojář commitnul migrační sql sript do svn. Dále musel změnu aplikovat u sebe lokálně minimálně na dvou databázích - jedna pro unit testy a druhá pro lokální vývoj. Dále musel změnu provést na testovacím prostředí na dalších třech databázích. Ostatní vývojáři si také museli tuto změnu aplikovat u sebe lokálně. No prostě opruz až na půdu.

Tuto příjemnou činnost jsme hodili na framework flyway. Má přesně takovou složitost, jakou jsme byli ochotni akceptovat. Do databáze přidal jednu tabulku, ze které je naprosto zřejmé, které migrační skripty už v databázi jsou aplikované. Vše je plně automatické a v režii spring beany. Jednoduché jako facka.

A jak jste se zaváděním continuous delivery vy?