Testcontainers, using Docker containers in JUnit tests

Junit sucks, use at least 5.0 or better switch to TestNG (see http://www.baeldung.com/junit-vs-testng for comparison)


https://www.javacodegeeks.com/2018/05/testcontainers-and-spring-boot.html

https://github.com/bijukunjummen/cities

https://www.testcontainers.org/usage.html#maven-dependencies

https://github.com/testcontainers/testcontainers-java-examples

https://github.com/testcontainers/testcontainers-java


https://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.testcontainers%22


To keep it really minimalistic, I have created a Maven Java project:

<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>org.pierre</groupId>
 <artifactId>testcontainer</artifactId>
 <version>1.0</version>
 <dependencies>
  <dependency>
   <groupId>org.testcontainers</groupId>
   <artifactId>testcontainers</artifactId>
   <version>1.7.3</version>
  </dependency>
  
  <dependency>
   <groupId>org.testcontainers</groupId>
   <artifactId>selenium</artifactId>
   <version>1.7.3</version>
  </dependency>
  
   
  
  <dependency>
   <groupId>org.seleniumhq.selenium</groupId>
   <artifactId>selenium-remote-driver</artifactId>
   <version>2.45.0</version>
  </dependency>
  <dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-api</artifactId>
   <version>1.7.7</version>
   <scope>provided</scope>
  </dependency>
  <dependency>
   <groupId>ch.qos.logback</groupId>
   <artifactId>logback-classic</artifactId>
   <version>1.1.2</version>
   <scope>test</scope>
  </dependency>
 </dependencies>

 <properties>
  <maven.compiler.target>1.8</maven.compiler.target>
  <maven.compiler.source>1.8</maven.compiler.source>
 </properties>
</project>

and copied this example

package org.pierre.testcontainer;

import org.junit.Rule;
import org.junit.Test;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.testcontainers.containers.BrowserWebDriverContainer;

import java.io.File;

import static org.rnorth.visibleassertions.VisibleAssertions.assertTrue;
import static org.testcontainers.containers.BrowserWebDriverContainer.VncRecordingMode.RECORD_ALL;


public class SeleniumContainerTest {

    @Rule
    public BrowserWebDriverContainer chrome = new BrowserWebDriverContainer()
                                                    .withDesiredCapabilities(DesiredCapabilities.chrome())
                                                    .withRecordingMode(RECORD_ALL, new File("target"));

    @Test
    public void simplePlainSeleniumTest() {
        RemoteWebDriver driver = chrome.getWebDriver();

        driver.get("https://wikipedia.org");
        WebElement searchInput = driver.findElementByName("search");

        searchInput.sendKeys("Rick Astley");
        searchInput.submit();

        WebElement otherPage = driver.findElementByLinkText("Rickrolling");
        otherPage.click();

        boolean expectedTextFound = driver.findElementsByCssSelector("p")
                .stream()
                .anyMatch(element -> element.getText().contains("meme"));

        assertTrue("The word 'meme' is found on a page about rickrolling", expectedTextFound);
}

}

The first time it failed with a SocketTimeoutException.... the second time it succeeded... I guess simply the Docker container was taking too much time to start.

If I do "docker images" I see richnorth/vnc-recorder and selenium/standalone-chrome-debug. If I do "docker ps -a" I see no trace of containers, probably they are removed at the end of test.


It looks really interesting! Convenient way to prepare a test environment in a fully automated way.

Ant, Junit and the forked JVM

I have a classpath defined as:


<path id="classpath.test">
<fileset dir="lib">
<include name="*.jar"/>
</fileset>
<pathelement location="/path/to/user_projects/domains/acme_osb/config/osb/"/>
</path>


I can trace it this way:

<echo message="${toString:classpath.test}"/>


and I use it in a junit task

<junit printsummary="true">
<classpath refid="classpath.test" />
<formatter type="brief" usefile="false"/>
<test name="com.acme.gu.ft.GUFT" outfile="junitout/GUFT">
<formatter type="xml"/>
</test>
</junit>



The alarming thing is that the Unit test is run NOT with the classpath I specify (classpath.test), but with the classpath being used to run ant.

I can trace it with System.getProperty("java.class.path")


The only way to run the Unit Test with the new Classpath is by specifying fork="on"

<junit printsummary="true" fork="on">


one hour wasted for this....

Hudson integration with JUnit

my ANT build.xml :

Once I configure Hudson with a valid ANT installation, running the test produces a
junitreport under the /home/a087/.hudson (hudson's home dir)

In fact the "Publish JUnit test result report " Hudson option accepts the parameter
"Test report XMLs" with the notation **/reports/*.xml relative to the /home/a087/.hudson directory! (it took some time to figure out)

The TESTS-TestSuites.xml file produced contains aggregate info on all the tests run:

  
      
      

      

....

  

And it happily appears on the "Test Result" tab


If you get
Fingerprinting not enabled on this build. Test aggregation requires fingerprinting

in Post-build Actions, enable "Record fingerprints of files to track usage "
and enter **/reports/*.xml in "Files to fingerprint"



More on TESTS-TestSuites.xml and JUnitReport

SOAPUI, JUnit and functional tests

Lovely tutorials by Meera Subbarao on SOAP-UI for functional tests:

http://soa.dzone.com/articles/functional-web-services-1

http://soa.dzone.com/articles/draft-functional-web-services--0

http://soa.dzone.com/articles/functional-web-services-testin-1


More here
http://www.soapui.org/Getting-Started/functional-testing.html

and with Maven:

http://technology.amis.nl/blog/7408/automatic-testing-oracle-service-bus-using-hudson-maven-and-soapui



On running SOAPUI tests from JUnit (Hudson):

where every SOAPUI project is executed in its own JUnit test, to make it easier to identify problems:

package dk.acme.dmr.service.test.integration;

import java.io.File;
import java.io.FilenameFilter;
import java.lang.reflect.Method;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;

import com.eviware.soapui.tools.SoapUITestCaseRunner;

/**
 * Run SOAPUI project files as test cases.
 * 
 * @author Acme A/S
 * @version 1.0
 * @since 1.0
 */
@RunWith(value = Parameterized.class)
public class SoapUITest {
  // The folder must be relative to this project
  private final static String SOAPUI_PROJECT_DIR = "src/test/resources/";

  private final static String ENDPOINT_VAR       = "endpoint";

  private final String        soapUiFileName;

  public SoapUITest(String soapUiFileName) {
    this.soapUiFileName = soapUiFileName;
  }

  @Parameterized.Parameters
  public static Collection<Object[]> soapUIprojectFiles() {
    File folder = new File(SOAPUI_PROJECT_DIR);
    OnlyExt onlyXml = new OnlyExt(".xml");
    String[] soapuiProjs = folder.list(onlyXml);
    List<Object[]> ret = new ArrayList<Object[]>();
    for (String s : soapuiProjs) {
      ret.add(new Object[] { s });
    }
    return ret;

  }

  @Test
  public void soapUITest() throws Exception {

    SoapUITestCaseRunner runner = new SoapUITestCaseRunner();
    runner.setProjectProperties(new String[] { new String(ENDPOINT_VAR + "=http://myserver:9001") });
    runner.setOutputFolder(System.getProperty("user.dir") + "/soapui-errors");
    runner.setProjectFile(SOAPUI_PROJECT_DIR + "/" + soapUiFileName);

    runner.run();

  }

  static class OnlyExt implements FilenameFilter {
    private final String ext;

    public OnlyExt(String _ext) {
      ext = _ext;
    }

    public boolean accept(File dir, String name) {

      return name.endsWith(ext);
    }
  }

}

I am still NOT persuaded that using SOAPUI for functional tests is better than using JUnit and Java stubs. If you go beyond the basics, SOAPUI and Groovy can be even more complex than the Java solution. I simply cannot accept writing complex code in a language that cannot be compiled and easily refactored.

Running JUnit tests to generate load on the system

JUnitTester1,2 etc are all our Test classes.
This code will create 5 threads running each all tests forever, with 500 ms pause at the end of each test sequence.
With this we can create load on the system.



package com.pierre.testall;

import com.pierre.junittester.JUnitTester1;
import com.pierre.junittester.JUnitTester2;

public class TestCatalog {
    public static Class[] ALL_TESTS = new Class[] {JUnitTester1.class, JUnitTester2.class};
}



package com.pierre.testall;

import junit.textui.TestRunner;

public class AllTests implements Runnable {
    public static void main(String[] args) {
        AllTests allTests = new AllTests();
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(allTests);
            thread.start();
        }
    }

    public void run() {
        while (true) {
            for (Class clazz : TestCatalog.ALL_TESTS) {
                TestRunner.run(clazz);
            }
            sleep(500);
        }
    }

    public void sleep(int ms) {
        try {
            Thread.sleep(ms);
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }
}


This  http://code.google.com/p/javatoolsforweblogic/source/browse/trunk/StressTest/src/com/pierre/test/StressTest.java
is also a good source of inspiration.

junit.framework.AssertionFailedError: No tests found in BLA

most likely you forgot to set ANT_HOME to the right value... I am using JUnit4, so I want to use the latest version of Ant:

export ANT_HOME=/weblogic/bea10.3/tools/eclipse_pkgs/2.0/eclipse_3.3.2/eclipse/plugins/org.apache.ant_1.7.0.v200706080842
ant -verbose


and remember to set

export CLASSPATH=/weblogic/bea10.3/tools/eclipse_pkgs/2.0/eclipse_3.3.2/eclipse/plugins/org.junit4_4.3.1/junit.jar


Ant is a piece of crap, JUnit even  more so. Why should a man struggle so much to run Unit Tests.