testify-project/testify

A Java Testing Framework faithful to sound testing principles and best practices.

Testify

Overview

Testify is an annotation driven Java Testing Framework that provides uniform and seamless way to write Unit, Integration, and System tests.

Features

• Uniform Annotations for Unit, Integration and System Testing
• Managed Test Case Configuration, Isolation, and Execution
• JSR-330 Dependency Injection Annotations Support
• JUnit 4 Testing Framework Support
• JUnit 5 Testing Framework Support
• Pluggable Mocking SPI (Mockito and EasyMock supported)
• Pluggable Local Test Resource SPI (HSQL, ElasticSearch, ZooKeeper, etc supported)
• Pluggable Virtual Test Resource SPI (Docker Container supported)
• Pluggable Server SPI (Undertow Supported)
• Pluggable Client SPI (JAX-RS Client supported)
• Spring Integration Testing
• Spring Boot System Testing
• Spring Web MVC System Testing
• HK2 Integration Testing
• Jersey 2 RESTful Web Services Framework System Testing
• Google Guice Integration Testing
• gRPC System Testing

Learning

• Testify documentation is available here.
• Example code can be found here.
• Read Java for Small Team eBook.

Issue Tracking

Report issues via the Github Issues. Think you've found a bug? Please consider submitting a reproduction project via the a new Github Issue.

Issue Pull Request

Pull requests are welcome.

Staying in Touch

• Gitter.
• Users Mailing List ([email protected])
• Developers Mailing List ([email protected])

Show Some Love

Testify Project does not have a revenue source and depends on support from the open source community. If you believe in our mission please consider donating:

License

The Testify is released under Apache Software License, Version 2.0.

Enjoy and keep on Testifying!

testify's Issues

Add Support for Docker Compose Virtual Resource

Docker alone is nice but having support for docker-compose would make it easy to test against external resources with many dependencies.

Add Support for Test Resource Reuse

Currently test resources are ephemeral. There are some use-cases where it is preferable to have test resources that are reusable. Default behavior can still be ephemeral but add an attribute called reuse to LocalResource, VirtualResource and RemoteResource to enable reuse.

Add support for multiple client implementations

See

• http://unirest.io/java.html
• http://square.github.io/okhttp/
• http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#rest-resttemplate
• https://developers.google.com/api-client-library/java/google-http-java-client/setup
• https://restlet.com/technical-resources/restlet-framework/guide/2.2/introduction/first-steps/first-client

Add Support for Kubernetes Virtual Resource

Docker alone is nice but having support for kubernetes would make it easy to test against external resources with many dependencies. I should be able to pass have a directory with kubernetes file or a single kubernetes file as my virtual resource value.

Improve Logging Support

As a top level framework testify should not be bundled with a SLF4J implementation. Currently Testify bundles Logback which causes an error in the event Logback version is not supported by Testify. Instead of the current implementation Testify should instead:

• Remove dependency on Logback
• Determine if there is a SLF4J implementation in the classpath and if there is use it.
• If no implementation of SL4J is found in the classpath fallback to an internal logging implementation.

The motivation for doing this work is to insure testify doesn't fail due to Logback implementation issues. For example:

Failed to instantiate [ch.qos.logback.classic.LoggerContext]
Reported exception:
java.lang.AbstractMethodError: ch.qos.logback.classic.pattern.EnsureExceptionHandling.process(Lch/qos/logback/core/Context;Lch/qos/logback/core/pattern/Converter;)V
	at ch.qos.logback.core.pattern.PatternLayoutBase.start(PatternLayoutBase.java:85)
	at ch.qos.logback.classic.encoder.PatternLayoutEncoder.start(PatternLayoutEncoder.java:28)
	at ch.qos.logback.classic.BasicConfigurator.configure(BasicConfigurator.java:50)
	at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:164)
	at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85)
	at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
	at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
	at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
	at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
	at org.testifyproject.core.util.LoggingUtil.<clinit>(LoggingUtil.java:38)
	at org.testifyproject.core.util.ExceptionUtil.<clinit>(ExceptionUtil.java:30)
	at org.testifyproject.core.util.ServiceLocatorUtil.insureNotEmpty(ServiceLocatorUtil.java:348)
	at org.testifyproject.core.util.ServiceLocatorUtil.getAll(ServiceLocatorUtil.java:315)
	at org.testifyproject.core.analyzer.TestClassAnalyzer.visitAnnotation(TestClassAnalyzer.java:74)
	at org.testifyproject.asm.ClassReader.accept(Unknown Source)
	at org.testifyproject.asm.ClassReader.accept(Unknown Source)
	at org.testifyproject.core.util.AnalyzerUtil.lambda$analyzeTestClass$0(AnalyzerUtil.java:63)
	at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
	at org.testifyproject.core.util.AnalyzerUtil.analyzeTestClass(AnalyzerUtil.java:55)
	at org.testifyproject.junit4.core.TestifyJUnit4CategoryFilter.shouldRun(TestifyJUnit4CategoryFilter.java:60)
	at org.junit.runners.ParentRunner.shouldRun(ParentRunner.java:434)
	at org.junit.runners.ParentRunner.filter(ParentRunner.java:382)
	at org.testifyproject.junit4.core.TestifyJUnit4TestRunner.<init>(TestifyJUnit4TestRunner.java:85)
	at org.testifyproject.junit4.UnitTest.<init>(UnitTest.java:40)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
	at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
	at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
	at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

Use Unix Socket for Docker Client Communication

Currently we HTTP communication is used. This is not ideal and requires extensive configuration. Try using unix socket for communicating with docker.

// Create a client based on DOCKER_HOST and DOCKER_CERT_PATH env vars
final DockerClient docker = DefaultDockerClient.builder().uri("unix:///var/run/docker.sock")
                .build();

// Pull an image
 docker.pull("busybox", new AnsiProgressHandler());

<dependency>
    <groupId>com.spotify</groupId>
    <artifactId>docker-client</artifactId>
    <version>8.14.5</version>
    <classifier>shaded</classifier>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>1.7.25</version>
</dependency>