JarCastingUnit Testing
Letzte Version: 4.2.0
Freigabedatum:
JUnit 5 (Bill of Materials)
org.junit : junit-bomThis Bill of Materials POM can be used to ease dependency management when referencing multiple JUnit artifacts using Gradle or Maven.
Letzte Version: 5.8.2
Freigabedatum:Letzte Version: 7.5
Freigabedatum:
Letzte Version: 4.2.0
Freigabedatum:
mockito-inline
org.mockito : mockito-inlineMockito preconfigured inline mock maker (intermediate and to be superseeded by automatic usage in a future version)
Letzte Version: 4.2.0
Freigabedatum:
Letzte Version: 2.4.2
Freigabedatum:
Letzte Version: 5.8.2
Freigabedatum:
JUnit Jupiter Engine
org.junit.jupiter : junit-jupiter-engineModule "junit-jupiter-engine" of JUnit 5.
Letzte Version: 5.8.2
Freigabedatum:
Letzte Version: 2.0.2-beta
Freigabedatum:
Letzte Version: 3.0.9
Freigabedatum:
JUnit Vintage Engine
org.junit.vintage : junit-vintage-engineModule "junit-vintage-engine" of JUnit 5.
Letzte Version: 5.8.2
Freigabedatum:
JUnit Jupiter Params
org.junit.jupiter : junit-jupiter-paramsModule "junit-jupiter-params" of JUnit 5.
Letzte Version: 5.8.2
Freigabedatum:
Letzte Version: 2.0.9
Freigabedatum:
OPS4J Pax Exam Driver JUnit4
org.ops4j.pax.exam : pax-exam-junit4Pax Exam Integration testing framework for Modern Java Platforms.
Letzte Version: 4.13.5
Freigabedatum:
Apache Groovy
org.codehaus.groovy : groovy-test-junit5Groovy: A powerful, dynamic language for the JVM
Letzte Version: 3.0.9
Freigabedatum:
Letzte Version: 2.0.9
Freigabedatum:
Letzte Version: 1.7.4
Freigabedatum:
JUnit Platform Launcher
org.junit.platform : junit-platform-launcherModule "junit-platform-launcher" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
Letzte Version: 5.8.2
Freigabedatum:
Arquillian TestRunner JUnit Container
org.jboss.arquillian.junit : arquillian-junit-containerJUnit Container Implementation for the Arquillian Project
Letzte Version: 1.7.0.Alpha10
Freigabedatum:Letzte Version: 1.1.9
Freigabedatum:
Testcontainers :: JUnit Jupiter Extension
org.testcontainers : junit-jupiterIsolated container management for Java code testing
Letzte Version: 1.16.3
Freigabedatum:
OPS4J Pax Exam JUnit Probe Invoker
org.ops4j.pax.exam : pax-exam-invoker-junitPax Exam Integration testing framework for Modern Java Platforms.
Letzte Version: 4.13.5
Freigabedatum:jmock-junit4
org.jmock : jmock-junit4Sonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 2.12.0
Freigabedatum:
Letzte Version: 7.2.3
Freigabedatum:
Letzte Version: 3.14.0
Freigabedatum:
Camel :: Test :: Spring:: JUnit5
org.apache.camel : camel-test-spring-junit5Camel unit testing with Spring and JUnit 5
Letzte Version: 3.14.0
Freigabedatum:
Camel :: Testcontainers :: JUnit 5
org.apache.camel : camel-testcontainers-junit5Camel support for testcontainers with JUnit 5
Letzte Version: 3.14.0
Freigabedatum:
JUnit Platform Engine API
org.junit.platform : junit-platform-engineModule "junit-platform-engine" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
Arquillian TestRunner TestNG Container
org.jboss.arquillian.testng : arquillian-testng-containerTestNG Container Implementation for the Arquillian Project
Letzte Version: 1.7.0.Alpha10
Freigabedatum:
Letzte Version: 2.0.9
Freigabedatum:
OPS4J Pax Exam - JUnit Support
org.ops4j.pax.exam : pax-exam-junitOPS4J Pax Exam - Integration testing framework for OSGi. Detailed information to be found at http://wiki.ops4j.org/display/ops4j/Pax+Exam.
Letzte Version: 1.2.4
Freigabedatum:
Camel :: Testcontainers :: Spring :: JUnit5
org.apache.camel : camel-testcontainers-spring-junit5Camel unit testing with Spring, testcontainers and JUnit 5
Letzte Version: 3.14.0
Freigabedatum:
JUnit Platform Commons
org.junit.platform : junit-platform-commonsModule "junit-platform-commons" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
Letzte Version: 1.1.1
Freigabedatum:
Letzte Version: 1.2.6
Freigabedatum:
JUnit Platform Runner
org.junit.platform : junit-platform-runnerModule "junit-platform-runner" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
OPS4J Pax Exam - JUnit Extender Implementation
org.ops4j.pax.exam : pax-exam-junit-extender-implOPS4J Pax Exam - Integration testing framework for OSGi. Detailed information to be found at http://wiki.ops4j.org/display/ops4j/Pax+Exam.
Letzte Version: 1.2.4
Freigabedatum:
Arquillian TestRunner JUnit Core
org.jboss.arquillian.junit : arquillian-junit-coreJUnit Implementation for the Arquillian Project
Letzte Version: 1.7.0.Alpha10
Freigabedatum:
Letzte Version: 2.0.9
Freigabedatum:Letzte Version: 2.25.4
Freigabedatum:
JUnit Jupiter Migration Support
org.junit.jupiter : junit-jupiter-migrationsupportModule "junit-jupiter-migrationsupport" of JUnit 5.
Letzte Version: 5.8.2
Freigabedatum:JGit - JUnit Utility Classes
org.eclipse.jgit : org.eclipse.jgit.junitUtility classes to support JUnit testing of JGit applications.
Letzte Version: 6.0.0.202111291000-r
Freigabedatum:
Arquillian TestRunner JUnit Standalone
org.jboss.arquillian.junit : arquillian-junit-standaloneJUnit Standalone Implementation for the Arquillian Project
Letzte Version: 1.7.0.Alpha10
Freigabedatum:
junit-dataprovider
com.tngtech.java : junit-dataproviderA TestNG like dataprovider runner for JUnit
Letzte Version: 1.13.1
Freigabedatum:Apache ServiceMix :: Bundles :: junit
org.apache.servicemix.bundles : org.apache.servicemix.bundles.junitThis OSGi bundle wraps junit 4.13.2 jar file.
Letzte Version: 4.13.2_1
Freigabedatum:
Che Plugin :: Java Testing :: JUnit IDE
org.eclipse.che.plugin : che-plugin-testing-junit-ideProvides version of third parties artifacts to use in Codenvy platform projects
Letzte Version: 7.0.0-rc-3.0
Freigabedatum:
Che Plugin :: Java Testing :: TestNG IDE
org.eclipse.che.plugin : che-plugin-testing-testng-ideProvides version of third parties artifacts to use in Codenvy platform projects
Letzte Version: 7.0.0-rc-3.0
Freigabedatum:
Letzte Version: 2.0.9
Freigabedatum:
OPS4J Pax Exam Driver TestNG
org.ops4j.pax.exam : pax-exam-testngPax Exam Integration testing framework for Modern Java Platforms.
Letzte Version: 4.13.5
Freigabedatum:
Letzte Version: 0.4.16
Freigabedatum:
Letzte Version: 2.23.16
Freigabedatum:Issue Keeper JUnit Connector
link.bek.tools : issue-keeper-junitIssue keeper is a tracking tool which makes the tests skipped in advance when they are blocked by the open issues.
Letzte Version: 4.12.5
Freigabedatum:
weld-junit5
org.jboss.weld : weld-junit5Set of JUnit extensions to enhance the testing of CDI components.
Letzte Version: 3.0.0.Final
Freigabedatum:
Letzte Version: 1.6.10
Freigabedatum:
kafka-junit5
com.salesforce.kafka.test : kafka-junit5This library wraps Kafka's embedded test cluster, allowing you to more easily create and run integration tests using JUnit against a "real" kafka server running within the context of your tests.
Letzte Version: 3.2.3
Freigabedatum:
Helidon Microprofile Tests JUnit5
io.helidon.microprofile.tests : helidon-microprofile-tests-junit5Integration with Junit5 to support tests with CDI injection
Letzte Version: 2.4.1
Freigabedatum:
JUnit Platform Console
org.junit.platform : junit-platform-consoleModule "junit-platform-console" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
Arquillian TestRunner TestNG Core
org.jboss.arquillian.testng : arquillian-testng-coreTestNG Implementations for the Arquillian Project
Letzte Version: 1.7.0.Alpha10
Freigabedatum:
ActiveMQ :: JUnit Rule
org.apache.activemq.tooling : activemq-junitJUnit Rule for Embedded ActiveMQ Brokers
Letzte Version: 5.16.3
Freigabedatum:
Che Plugin :: Java Testing :: JUnit Runtime
org.eclipse.che.plugin : che-plugin-testing-junit-runtimeProvides version of third parties artifacts to use in Codenvy platform projects
Letzte Version: 7.0.0-rc-3.0
Freigabedatum:
Che Plugin :: Java Testing :: TestNG Runtime
org.eclipse.che.plugin : che-plugin-testing-testng-runtimeProvides version of third parties artifacts to use in Codenvy platform projects
Letzte Version: 7.0.0-rc-3.0
Freigabedatum:
Che Plugin :: Java Testing :: JUnit Server
org.eclipse.che.plugin : che-plugin-testing-junit-serverProvides version of third parties artifacts to use in Codenvy platform projects
Letzte Version: 7.0.0-rc-3.0
Freigabedatum:
Che Plugin :: Java Testing :: TestNG Server
org.eclipse.che.plugin : che-plugin-testing-testng-serverProvides version of third parties artifacts to use in Codenvy platform projects
Letzte Version: 7.0.0-rc-3.0
Freigabedatum:Letzte Version: 1.10.12
Freigabedatum:
OPS4J Pax Exam - JUnit Extender API
org.ops4j.pax.exam : pax-exam-junit-extenderOPS4J Pax Exam - Integration testing framework for OSGi. Detailed information to be found at http://wiki.ops4j.org/display/ops4j/Pax+Exam.
Letzte Version: 1.2.4
Freigabedatum:
Letzte Version: 3.0.0-M5
Freigabedatum:ActiveMQ Artemis JUnit Rules
org.apache.activemq : artemis-junitThe Apache Software Foundation provides support for the Apache community of open-source software projects. The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users.
Letzte Version: 2.20.0
Freigabedatum:
Cucumber-JVM: JUnit Platform Engine
io.cucumber : cucumber-junit-platform-engineCucumber for the JVM
Letzte Version: 7.2.3
Freigabedatum:
Letzte Version: 1.6.10
Freigabedatum:
Letzte Version: 3.0.0-M5
Freigabedatum:
ArchUnit
com.tngtech.archunit : archunit-junit5-engineA Java architecture test library, to specify and assert architecture rules in plain Java - Module 'archunit-junit5-engine'
Letzte Version: 0.22.0
Freigabedatum:
JUnit Platform Suite API
org.junit.platform : junit-platform-suite-apiModule "junit-platform-suite-api" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
Infinispan Server JUnit 4.x Test Driver
org.infinispan : infinispan-server-testdriver-junit4Infinispan Server Test Driver for JUnit 4.x
Letzte Version: 13.0.5.Final
Freigabedatum:
ArchUnit
com.tngtech.archunit : archunit-junit5-apiA Java architecture test library, to specify and assert architecture rules in plain Java - Module 'archunit-junit5-api'
Letzte Version: 0.22.0
Freigabedatum:Letzte Version: 1.5.0
Freigabedatum:JUnitBenchmarks
com.carrotsearch : junit-benchmarksA framework for writing performance micro-benchmarks using JUnit4 annotations.
Letzte Version: 0.7.2
Freigabedatum:
JUnit-Interface
com.novocode : junit-interfaceAn implementation of sbt's test interface for JUnit 4
Letzte Version: 0.11
Freigabedatum:Letzte Version: 2.2.0
Freigabedatum:
Letzte Version: 2.0.9
Freigabedatum:
Infinispan Server JUnit 5.x Test Driver
org.infinispan : infinispan-server-testdriver-junit5Infinispan Server Test Driver for JUnit 5.x
Letzte Version: 13.0.5.Final
Freigabedatum:Letzte Version: 3.4.2
Freigabedatum:jMock JUnit 3 Extension
org.jmock : jmock-junit3Sonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 2.12.0
Freigabedatum:
Letzte Version: 1.6.10
Freigabedatum:
Mockito Groovy Support
com.cyrusinnovation : mockito-groovy-supportA fix to allow you to use Mockito with Groovy
Letzte Version: 1.3
Freigabedatum:
Letzte Version: 2.17.2
Freigabedatum:Apache Sling Testing Sling Mock JUnit 4
org.apache.sling : org.apache.sling.testing.sling-mock.junit4Mock implementation of selected Sling APIs.
Letzte Version: 3.2.2
Freigabedatum:Apache Directory JUnit Add-ons
org.apache.directory.junit : junit-addonsCustom build tools used by the Apache Directory project.
Letzte Version: 2.0.1
Freigabedatum:
weld-junit4
org.jboss.weld : weld-junit4Set of JUnit extensions to enhance the testing of CDI components.
Letzte Version: 3.0.0.Final
Freigabedatum:Letzte Version: 1.4
Freigabedatum:
PowerMock
org.powermock : powermock-module-junit4-rule-agentPowerMock support module for JUnit 4.x rules with Java agent
Letzte Version: 2.0.9
Freigabedatum:
Letzte Version: 2.0.0.0
Freigabedatum:mockito-configuration
org.opendaylight.yangtools : mockito-configurationDefault mockito configuration
Letzte Version: 7.0.12
Freigabedatum:
bootique-junit5: unit/integration test framework for Bootique apps
io.bootique : bootique-junit5Provides a test framework on top of Bootique.
Letzte Version: 2.0.RC1
Freigabedatum:RandomizedTesting JUnit4 ANT Task
com.carrotsearch.randomizedtesting : junit4-antJUnit test runner and plugins for running JUnit tests with pseudo-randomness.
Letzte Version: 2.7.9
Freigabedatum:JGit - JUnit Http Utility Classes
org.eclipse.jgit : org.eclipse.jgit.junit.httpUtility classes to support Http based JUnit testing of JGit applications.
Letzte Version: 6.0.0.202111291000-r
Freigabedatum:JUnit Toolbox
com.googlecode.junit-toolbox : junit-toolboxUseful classes for writing automated tests with JUnit
Letzte Version: 2.4
Freigabedatum:FEST Swing - JUnit 4.5 Extension
org.easytesting : fest-swing-junit-4.5JUnit 4.5-specific extension for FEST-Swing
Letzte Version: 1.2.1
Freigabedatum:Letzte Version: 1.6.0
Freigabedatum:Transitional :: JUnit 4 stub
io.syndesis.transitional : junit4-stubStub used instead of JUnit 4 dependency. These classes are used only so that the class hiearchy can be maintained. Functionality of these classes is not used, that's why they're empty, but they're needed to successfuly compile 3rd party dependencies without introducing junit:junit (JUnit 4) dependency. For one such case see: https://github.com/testcontainers/testcontainers-java/issues/970#issuecomment-625044008
Letzte Version: 1.13.2
Freigabedatum:
JUnit Platform Test Kit
org.junit.platform : junit-platform-testkitModule "junit-platform-testkit" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:Letzte Version: 0.268
Freigabedatum:
Letzte Version: 1.2.7
Freigabedatum:
docker-compose-rule-junit4
com.palantir.docker.compose : docker-compose-rule-junit4Palantir open source project
Letzte Version: 1.7.0
Freigabedatum:
Letzte Version: 350
Freigabedatum:OPS4J Pax Tipi - junit
org.ops4j.pax.tipi : org.ops4j.pax.tipi.junitThis OSGi bundle wraps junit-4.12
Letzte Version: 4.12.0.1
Freigabedatum:
org-netbeans-libs-junit4
org.netbeans.api : org-netbeans-libs-junit4Apache NetBeans is an integrated development environment, tooling platform, and application framework.
Letzte Version: RELEASE126
Freigabedatum:
JUnit Platform Surefire Provider
org.junit.platform : junit-platform-surefire-providerModule "junit-platform-surefire-provider" of JUnit 5.
Letzte Version: 1.3.2
Freigabedatum:
Letzte Version: 3.6.2
Freigabedatum:
Letzte Version: 3.6.2
Freigabedatum:
docker-proxy-rule-junit4
com.palantir.docker.proxy : docker-proxy-rule-junit4Palantir open source project
Letzte Version: 1.5.0
Freigabedatum:JGit - JUnit Ssh Utility Classes
org.eclipse.jgit : org.eclipse.jgit.junit.sshUtility classes to support Ssh based JUnit testing of JGit applications.
Letzte Version: 6.0.0.202111291000-r
Freigabedatum:
Letzte Version: 7.2.3
Freigabedatum:
Letzte Version: 5.3.5
Freigabedatum:
Ajocado JUnit Integration
org.jboss.arquillian.ajocado : arquillian-ajocado-junitStarting point for integration Ajocado to JUnit test suites
Letzte Version: 1.0.0.CR2
Freigabedatum:
Letzte Version: 5.3.5
Freigabedatum:
Letzte Version: 2.9.0
Freigabedatum:
Letzte Version: 4.0.15-alpha
Freigabedatum:Letzte Version: 1.6.0
Freigabedatum:
Letzte Version: 4.0.16-alpha
Freigabedatum:
bootique-jdbc-junit5-derby: JUnit5 helper classes for unit tests using in-memory Derby DB
io.bootique.jdbc : bootique-jdbc-junit5-derbyProvides JUnit5-based helper classes for unit tests using in-memory Derby DB
Letzte Version: 2.0.RC1
Freigabedatum:
BlockHound JUnit Platform Integration
io.projectreactor.tools : blockhound-junit-platformIntegrates the BlockHound Java agent to detect blocking calls in JUnit Platform-based tests.
Letzte Version: 1.0.6.RELEASE
Freigabedatum:MyFaces Extensions-CDI JUnit-Support Module
org.apache.myfaces.extensions.cdi.test : myfaces-extcdi-junit-support-moduleThe MyFaces project is home of the first free open source JavaServer Faces implementation as well as some useful JSF component libraries and other convenient JSF stuff.
Letzte Version: 1.0.6
Freigabedatum:
JUnit Platform Reporting
org.junit.platform : junit-platform-reportingModule "junit-platform-reporting" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
Letzte Version: 2.5.29
Freigabedatum:Letzte Version: 4.7-201002261215
Freigabedatum:
PowerMock
org.powermock : powermock-module-testng-commonPowerMock module for TestNG. Common classes
Letzte Version: 2.0.9
Freigabedatum:
FluentLenium JUnit Jupiter
org.fluentlenium : fluentlenium-junit-jupiterJUnit 5.x Adapter for FluentLenium
Letzte Version: 5.0.2
Freigabedatum:
Letzte Version: 3.0.0
Freigabedatum:
Scope Rule for JUnit4
com.undefinedlabs.scope : scope-rule-junit4Scope is a APM for tests to give engineering teams unprecedented visibility into their CI process to quickly identify, troubleshoot and fix failed builds. This artifact contains the classes to instrument the JUnit4 tests.
Letzte Version: 0.15.1-beta.2
Freigabedatum:junit-servers-jetty
com.github.mjeanroy : junit-servers-jettyAdd Jetty Embedded Server to your junit tests case.
Letzte Version: 2.1.0
Freigabedatum:
SureFire JUnitCore Runner
org.apache.maven.surefire : surefire-junit47SureFire JUnitCore (JUnit 4.7+) Runner
Letzte Version: 3.0.0-M5
Freigabedatum:
Apache Geode
org.apache.geode : geode-junitApache Geode provides a database-like consistency model, reliable transaction processing and a shared-nothing architecture to maintain very low latency performance with high concurrency processing
Letzte Version: 1.14.2
Freigabedatum:
Scope Rule for JUnit5
com.undefinedlabs.scope : scope-rule-junit5Scope is a APM for tests to give engineering teams unprecedented visibility into their CI process to quickly identify, troubleshoot and fix failed builds. This artifact contains the classes to instrument the JUnit5 tests.
Letzte Version: 0.15.1-beta.2
Freigabedatum:
Scope Runner for JUnit5
com.undefinedlabs.scope : scope-runner-junit5Scope is a APM for tests to give engineering teams unprecedented visibility into their CI process to quickly identify, troubleshoot and fix failed builds. This artifact contains the classes to instrument the JUnit5 runner.
Letzte Version: 0.15.1-beta.2
Freigabedatum:
PowerMock
org.powermock : powermock-module-junit4-rulePowerMock support module for JUnit 4.x rules.
Letzte Version: 2.0.9
Freigabedatum:
Scope Runner for JUnit4
com.undefinedlabs.scope : scope-runner-junit4Scope is a APM for tests to give engineering teams unprecedented visibility into their CI process to quickly identify, troubleshoot and fix failed builds. This artifact contains the classes to instrument the JUnit4 runner.
Letzte Version: 0.15.1-beta.2
Freigabedatum:
Scope Rule for TestNG
com.undefinedlabs.scope : scope-rule-testngScope is a APM for tests to give engineering teams unprecedented visibility into their CI process to quickly identify, troubleshoot and fix failed builds. This artifact contains the classes to instrument the TestNG tests.
Letzte Version: 0.15.1-beta.2
Freigabedatum:
Scope Runner for JUnit4 PowerMock
com.undefinedlabs.scope : scope-runner-junit4-powermockScope is a APM for tests to give engineering teams unprecedented visibility into their CI process to quickly identify, troubleshoot and fix failed builds. This artifact contains the classes to instrument the PowerMock runner for JUnit4.
Letzte Version: 0.15.1-beta.2
Freigabedatum:
Letzte Version: 2.5.29
Freigabedatum:
Scope Runner for TestNG
com.undefinedlabs.scope : scope-runner-testngScope is a APM for tests to give engineering teams unprecedented visibility into their CI process to quickly identify, troubleshoot and fix failed builds. This artifact contains the classes to instrument the TestNG runner.
Letzte Version: 0.15.1-beta.2
Freigabedatum:Letzte Version: 1.3.1
Freigabedatum:JUnit Platform Native
org.graalvm.buildtools : junit-platform-nativeJUnit Platform support for GraalVM Native Image
Letzte Version: 0.9.9
Freigabedatum:
Quarkus - Test Framework - JUnit 5
io.quarkus : quarkus-junit5Build parent to bring in required dependencies
Letzte Version: 2.7.0.CR1
Freigabedatum:
JUnit 3/4 SuiteConfiguration Test Runner
org.sonatype.http-testing-harness : junit-runner${project.name}
Letzte Version: 0.11
Freigabedatum:
Letzte Version: 2.17.2
Freigabedatum:Spock Framework - JUnit 4
org.spockframework : spock-junit4Spock is a testing and specification framework for Java and Groovy applications. What makes it stand out from the crowd is its beautiful and highly expressive specification language. Thanks to its JUnit runner, Spock is compatible with most IDEs, build tools, and continuous integration servers. Spock is inspired from JUnit, jMock, RSpec, Groovy, Scala, Vulcans, and other fascinating life forms.
Letzte Version: 2.1-M2-groovy-3.0
Freigabedatum:
Letzte Version: 0.1.1
Freigabedatum:
PowerMock
org.powermock : powermock-classloading-xstreamPerforms classloader deep-cloning using X-Stream.
Letzte Version: 2.0.9
Freigabedatum:
Arquillian Cube Docker JUnit Rule
org.arquillian.cube : arquillian-cube-docker-junit-ruleArquillian Cube Extension to integrate Arquillian to Docker
Letzte Version: 1.18.2
Freigabedatum:Letzte Version: 2.0.0-alpha-2
Freigabedatum:Letzte Version: 4.1.0
Freigabedatum:
bootique-jetty-junit5: JUnit 5 utilities to start Jetty on a dynamic port
io.bootique.jetty : bootique-jetty-junit5JUnit 5 utilities to start Jetty on a dynamically determined port and provide a client that can be used by the tests
Letzte Version: 2.0.RC1
Freigabedatum:Letzte Version: 4.10.6
Freigabedatum:Letzte Version: 5.1.0
Freigabedatum:Letzte Version: 2.0.0-alpha-2
Freigabedatum:
Allure TestNG Adaptor
ru.yandex.qatools.allure : allure-testng-adaptorSonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 1.5.4
Freigabedatum:Vert.x JUnit 5 support :: Core
io.vertx : vertx-junit5Sonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 4.2.4
Freigabedatum:
Letzte Version: 1.0.1
Freigabedatum:
bootique-cayenne42-junit5: JUnit 5-based helper classes for unit tests with Cayenne stack
io.bootique.cayenne : bootique-cayenne42-junit5Provides JUnit 5 based helper classes for unit tests with Cayenne stack
Letzte Version: 2.0.RC1
Freigabedatum:junit-quickcheck-generators
com.pholser : junit-quickcheck-generatorsProperty-based testing, JUnit-style: basic generators
Letzte Version: 1.0
Freigabedatum:
Letzte Version: 2.17.2
Freigabedatum:
jqassistant.plugin.junit
com.buschmais.jqassistant.plugin : jqassistant.plugin.junitFramework for structural analysis of Java applications.
Letzte Version: 1.1.4
Freigabedatum:Letzte Version: 6.1.0
Freigabedatum:MockServer JUnit Jupiter Integration
org.mock-server : mockserver-junit-jupiterA JUnit5 Extension for MockServer
Letzte Version: 5.11.2
Freigabedatum:
Quarkus - Test Framework - JUnit 5 Internal Test Framework
io.quarkus : quarkus-junit5-internalA runner for unit tests, intended for testing Quarkus rather than for end user consumption.
Letzte Version: 2.7.0.CR1
Freigabedatum:Letzte Version: 4.13.2
Freigabedatum:
Allure jUnit Adaptor
ru.yandex.qatools.allure : allure-junit-adaptorSonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 1.5.4
Freigabedatum:
Arquillian Cube Docker JUnit 5
org.arquillian.cube : arquillian-cube-docker-junit5Arquillian Cube Extension to integrate Arquillian to Docker
Letzte Version: 1.18.2
Freigabedatum:
Letzte Version: 1.2.6
Freigabedatum:Apache Sling Testing OSGi Mock JUnit 4
org.apache.sling : org.apache.sling.testing.osgi-mock.junit4Mock implementation of selected OSGi APIs.
Letzte Version: 3.2.2
Freigabedatum:
Betamax
software.betamax : betamax-junitBetamax is a tool for mocking external HTTP resources such as web services and REST APIs in your tests.
Letzte Version: 2.0.1
Freigabedatum:Junit4Osgi
org.apache.felix : org.apache.felix.ipojo.junit4osgiApache Felix is an OSGi implementation.
Letzte Version: 1.0.0
Freigabedatum:
S3Mock - Testsupport - JUnit4
com.adobe.testing : s3mock-junit4S3 mock implementation to be used for hermetic testing
Letzte Version: 2.3.3
Freigabedatum:
Letzte Version: 4.1.8
Freigabedatum:Letzte Version: 2.1.25
Freigabedatum:Apache Sling JUnit Core
org.apache.sling : org.apache.sling.junit.coreRuns JUnit tests in an OSGi framework and provides the JUnit libraries
Letzte Version: 1.1.6
Freigabedatum:Letzte Version: 1.2.59
Freigabedatum:
Burst JUnit 4 Integration
com.squareup.burst : burst-junit4Burst is a unit testing library for varying test data.
Letzte Version: 1.2.0
Freigabedatum:
Letzte Version: 0.2.2
Freigabedatum:junit-quickcheck-core
com.pholser : junit-quickcheck-coreProperty-based testing, JUnit-style: core functionality
Letzte Version: 1.0
Freigabedatum:
junit5
au.com.dius.pact.provider : junit5# Pact Junit 5 Extension ## Dependency The library is available on maven central using: * group-id = `au.com.dius.pact.provider` * artifact-id = `junit5` * version-id = `4.1.x` ## Overview For writing Pact verification tests with JUnit 5, there is an JUnit 5 Invocation Context Provider that you can use with the `@TestTemplate` annotation. This will generate a test for each interaction found for the pact files for the provider. To use it, add the `@Provider` and one of the pact source annotations to your test class (as per a JUnit 4 test), then add a method annotated with `@TestTemplate` and `@ExtendWith(PactVerificationInvocationContextProvider.class)` that takes a `PactVerificationContext` parameter. You will need to call `verifyInteraction()` on the context parameter in your test template method. For example: ```java @Provider("myAwesomeService") @PactFolder("pacts") public class ContractVerificationTest { @TestTemplate @ExtendWith(PactVerificationInvocationContextProvider.class) void pactVerificationTestTemplate(PactVerificationContext context) { context.verifyInteraction(); } } ``` For details on the provider and pact source annotations, refer to the [Pact junit runner](../junit/README.md) docs. ## Test target You can set the test target (the object that defines the target of the test, which should point to your provider) on the `PactVerificationContext`, but you need to do this in a before test method (annotated with `@BeforeEach`). There are three different test targets you can use: `HttpTestTarget`, `HttpsTestTarget` and `MessageTestTarget`. For example: ```java @BeforeEach void before(PactVerificationContext context) { context.setTarget(HttpTestTarget.fromUrl(new URL(myProviderUrl))); // or something like // context.setTarget(new HttpTestTarget("localhost", myProviderPort, "/")); } ``` ### HttpTestTarget `HttpTestTarget` accepts the following options: | Option | Type | Default | Description | | ------ | ---- | ------- | ----------- | | host | String | localhost | The hostname to use to access the provider | | port | Int | 8080 | The port the provider is running on | | path | String | "/" | The base path the provider is mounted on | | httpClientFactory | () -> IHttpClientFactory | Default Factory | Callback used to override the HTTP client factory | ### HttpsTestTarget `HttpsTestTarget` accepts the following options: | Option | Type | Default | Description | | ------ | ---- | ------- | ----------- | | host | String | localhost | The hostname to use to access the provider | | port | Int | 8443 | The port the provider is running on | | path | String | "/" | The base path the provider is mounted on | | insecure | Boolean | false | Disables the standard TLS verification used with HTTPS connections | | httpClientFactory | () -> IHttpClientFactory | Default Factory | Callback used to override the HTTP client factory | ### MessageTestTarget `MessageTestTarget` accepts the following options: | Option | Type | Default | Description | | ------ | ---- | ------- | ----------- | | packagesToScan | List&lt;String&gt; | empty List | The Java packages to scan to find classes with annotated methods. If your methods are on your test class, you don't need to supply a value for this. | | classLoader | ClassLoader? | null | Class loader to use to load the classes with annotated methods | ## !! Important note for Maven users !! If you use Maven to run your tests, you will have to make sure that the Maven Surefire plugin is at least version 2.22.1 and configured to use an isolated classpath. For example, configure it by adding the following to your POM: ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.22.1</version> <configuration> <useSystemClassLoader>false</useSystemClassLoader> </configuration> </plugin> ``` ### IMPORTANT NOTE!!!: JVM system properties needs to be set on the test JVM if your build is running with Gradle or Maven. Gradle and Maven do not pass in the system properties in to the test JVM from the command line. The system properties specified on the command line only control the build JVM (the one that runs Gradle or Maven), but the tests will run in a new JVM. See [Maven Surefire Using System Properties](https://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html) and [Gradle Test docs](https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html#org.gradle.api.tasks.testing.Test:systemProperties). ### For Message Tests and Spring and Maven If you are using Spring (or Springboot), and want to have values injected into your test, you need to ensure that the same class loader is used to execute your annotated test method as Spring is using to inject the values. In particular, options like the Maven Surefire plugin's `forkCount == 0` can impact this. Either don't supply any packages to scan (this will use the default class loader and the annotated methods **have** to be on your test class), or you can provide the classloader to use as the second parameter to `MessageTestTarget`. ## Provider State Methods Provider State Methods work in the same way as with JUnit 4 tests, refer to the [Pact junit runner](../junit/README.md) docs. ### Using multiple classes for the state change methods If you have a large number of state change methods, you can split things up by moving them to other classes. You will need to specify the additional classes on the test context in a `Before` method. Do this with the `withStateHandler` or `setStateHandlers` methods. See [StateAnnotationsOnAdditionalClassTest](https://github.com/DiUS/pact-jvm/blob/master/provider/junit5/src/test/java/au/com/dius/pact/provider/junit5/StateAnnotationsOnAdditionalClassTest.java) for an example. ## Modifying the requests before they are sent **Important Note:** You should only use this feature for things that can not be persisted in the pact file. By modifying the request, you are potentially modifying the contract from the consumer tests! **NOTE: JUnit 5 tests do not use `@TargetRequestFilter`** Sometimes you may need to add things to the requests that can't be persisted in a pact file. Examples of these would be authentication tokens, which have a small life span. The Http and Https test targets support injecting the request that will executed into the test template method (of type `org.apache.http.HttpRequest` for versions 4.2.x and before, `org.apache.hc.core5.http.HttpRequest` for versions 4.3.0+). You can then add things to the request before calling the `verifyInteraction()` method. For example to add a header: ```java @TestTemplate @ExtendWith(PactVerificationInvocationContextProvider.class) void testTemplate(PactVerificationContext context, HttpRequest request) { // This will add a header to the request request.addHeader("X-Auth-Token", "1234"); context.verifyInteraction(); } ``` ## Objects that can be injected into the test methods You can inject the following objects into your test methods (just like the `PactVerificationContext`). They will be null if injected before the supported phase. | Object | Can be injected from phase | Description | | ------ | --------------- | ----------- | | PactVerificationContext | @BeforeEach | The context to use to execute the interaction test | | Pact | any | The Pact model for the test | | Interaction | any | The Interaction model for the test | | HttpRequest | @TestTemplate | The request that is going to be executed (only for HTTP and HTTPS targets) | | ProviderVerifier | @TestTemplate | The verifier instance that is used to verify the interaction | ## Allowing the test to pass when no pacts are found to verify (version 4.0.7+) By default, the test will fail with an exception if no pacts were found to verify. This can be overridden by adding the `@IgnoreNoPactsToVerify` annotation to the test class. For this to work, you test class will need to be able to receive null values for any of the injected parameters. ## Overriding the handling of a body data type **NOTE: version 4.1.3+** By default, bodies will be handled based on their content types. For binary contents, the bodies will be base64 encoded when written to the Pact file and then decoded again when the file is loaded. You can change this with an override property: `pact.content_type.override.<TYPE>.<SUBTYPE>=text|json|binary`. For instance, setting `pact.content_type.override.application.pdf=text` will treat PDF bodies as a text type and not encode/decode them. ### Controlling the generation of diffs **NOTE: version 4.2.7+** When there are mismatches with large bodies the calculation of the diff can take a long time . You can turn off the generation of the diffs with the JVM system property: `pact.verifier.generateDiff=true|false|<dataSize>`, where `dataSize`, if specified, must be a valid data size (for instance `100kb` or `1mb`). This will turn off the diff calculation for payloads that exceed this size. For instance, setting `pact.verifier.generateDiff=false` will turn off the generation of diffs for all bodies, while `pact.verifier.generateDiff=512kb` will only turn off the diffs if the actual or expected body is larger than 512kb. # Publishing verification results to a Pact Broker For pacts that are loaded from a Pact Broker, the results of running the verification can be published back to the broker against the URL for the pact. You will be able to see the result on the Pact Broker home screen. You need to set the version of the provider that is verified using the `pact.provider.version` system property. To enable publishing of results, set the Java system property or environment variable `pact.verifier.publishResults` to `true`. ### IMPORTANT NOTE!!!: this property needs to be set on the test JVM if your build is running with Gradle or Maven. Gradle and Maven do not pass in the system properties in to the test JVM from the command line. The system properties specified on the command line only control the build JVM (the one that runs Gradle or Maven), but the tests will run in a new JVM. See [Maven Surefire Using System Properties](https://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html) and [Gradle Test docs](https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html#org.gradle.api.tasks.testing.Test:systemProperties). ## Tagging the provider before verification results are published [4.0.1+] You can have a tag pushed against the provider version before the verification results are published. To do this you need set the `pact.provider.tag` JVM system property to the tag value. From 4.1.8+, you can specify multiple tags with a comma separated string for the `pact.provider.tag` system property. ## Setting the provider branch before verification results are published [4.3.0-beta.7+] Pact Broker version 2.86.0 or later You can have a branch pushed against the provider version before the verification results are published. To do this you need set the `pact.provider.branch` JVM system property to the branch value. ## Setting the build URL for verification results [4.3.2+] You can specify a URL to link to your CI build output. To do this you need to set the `pact.verifier.buildUrl` JVM system property to the URL value. # Pending Pact Support (version 4.1.0 and later) If your Pact broker supports pending pacts, you can enable support for that by enabling that on your Pact broker annotation or with JVM system properties. You also need to provide the tags that will be published with your provider's verification results. The broker will then label any pacts found that don't have a successful verification result as pending. That way, if they fail verification, the verifier will ignore those failures and not fail the build. For example, with annotation: ```java @Provider("Activity Service") @PactBroker(host = "test.pactflow.io", tags = {"test"}, scheme = "https", enablePendingPacts = "true", providerTags = "master" ) public class PactJUnitTest { ``` You can also use the `pactbroker.enablePending` and `pactbroker.providerTags` JVM system properties. Then any pending pacts will not cause a build failure. # Work In Progress (WIP) Pact Support (version 4.1.5 and later) WIP pacts work in the same way as with JUnit 4 tests, refer to the [Pact junit runner](../junit/README.md) docs. # Verifying V4 Pact files that require plugins (version 4.3.0+) Pact files that require plugins can be verified with version 4.3.0+. For details on how plugins work, see the [Pact plugin project](https://github.com/pact-foundation/pact-plugins). Each required plugin is defined in the `plugins` section in the Pact metadata in the Pact file. The plugins will be loaded from the plugin directory. By default, this is `~/.pact/plugins` or the value of the `PACT_PLUGIN_DIR` environment variable. Each plugin required by the Pact file must be installed there. You will need to follow the installation instructions for each plugin, but the default is to unpack the plugin into a sub-directory `<plugin-name>-<plugin-version>` (i.e., for the Protobuf plugin 0.0.0 it will be `protobuf-0.0.0`). The plugin manifest file must be present for the plugin to be able to be loaded. # Test Analytics We are tracking anonymous analytics to gather important usage statistics like JVM version and operating system. To disable tracking, set the 'pact_do_not_track' system property or environment variable to 'true'.
Letzte Version: 4.3.4
Freigabedatum:
JUnit Platform Flight Recorder Support
org.junit.platform : junit-platform-jfrModule "junit-platform-jfr" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:junit-servers-tomcat
com.github.mjeanroy : junit-servers-tomcatAdd Tomcat Embedded Server to your junit tests case.
Letzte Version: 2.1.0
Freigabedatum:
Letzte Version: 3.2.0.0-M2
Freigabedatum:
junit5
au.com.dius.pact.consumer : junit5pact-jvm-consumer-junit5 ======================== JUnit 5 support for Pact consumer tests ## Dependency The library is available on maven central using: * group-id = `au.com.dius.pact.consumer` * artifact-id = `junit5` * version-id = `4.2.X` ## Usage ### 1. Add the Pact consumer test extension to the test class. To write Pact consumer tests with JUnit 5, you need to add `@ExtendWith(PactConsumerTestExt)` to your test class. This replaces the `PactRunner` used for JUnit 4 tests. The rest of the test follows a similar pattern as for JUnit 4 tests. ```java @ExtendWith(PactConsumerTestExt.class) class ExampleJavaConsumerPactTest { ``` ### 2. create a method annotated with `@Pact` that returns the interactions for the test For each test (as with JUnit 4), you need to define a method annotated with the `@Pact` annotation that returns the interactions for the test. ```java @Pact(provider="ArticlesProvider", consumer="test_consumer") public RequestResponsePact createPact(PactDslWithProvider builder) { return builder .given("test state") .uponReceiving("ExampleJavaConsumerPactTest test interaction") .path("/articles.json") .method("GET") .willRespondWith() .status(200) .body("{\"responsetest\": true}") .toPact(); } ``` ### 3. Link the mock server with the interactions for the test with `@PactTestFor` Then the final step is to use the `@PactTestFor` annotation to tell the Pact extension how to setup the Pact test. You can either put this annotation on the test class, or on the test method. For examples see [ArticlesTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit5/src/test/java/au/com/dius/pact/consumer/junit5/ArticlesTest.java) and [MultiTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit5/src/test/groovy/au/com/dius/pact/consumer/junit5/MultiTest.groovy). The `@PactTestFor` annotation allows you to control the mock server in the same way as the JUnit 4 `PactProviderRule`. It allows you to set the hostname to bind to (default is `localhost`) and the port (default is to use a random port). You can also set the Pact specification version to use (default is V3). ```java @ExtendWith(PactConsumerTestExt.class) @PactTestFor(providerName = "ArticlesProvider") public class ExampleJavaConsumerPactTest { ``` **NOTE on the hostname**: The mock server runs in the same JVM as the test, so the only valid values for hostname are: | hostname | result | | -------- | ------ | | `localhost` | binds to the address that localhost points to (normally the loopback adapter) | | `127.0.0.1` or `::1` | binds to the loopback adapter | | host name | binds to the default interface that the host machines DNS name resolves to | | `0.0.0.0` or `::` | binds to the all interfaces on the host machine | #### Matching the interactions by provider name If you set the `providerName` on the `@PactTestFor` annotation, then the first method with a `@Pact` annotation with the same provider name will be used. See [ArticlesTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit5/src/test/java/au/com/dius/pact/consumer/junit5/ArticlesTest.java) for an example. #### Matching the interactions by method name If you set the `pactMethod` on the `@PactTestFor` annotation, then the method with the provided name will be used (it still needs a `@Pact` annotation). See [MultiTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit5/src/test/groovy/au/com/dius/pact/consumer/junit5/MultiTest.groovy) for an example. ### Injecting the mock server into the test You can get the mock server injected into the test method by adding a `MockServer` parameter to the test method. ```java @Test void test(MockServer mockServer) throws IOException { HttpResponse httpResponse = Request.Get(mockServer.getUrl() + "/articles.json").execute().returnResponse(); assertThat(httpResponse.getStatusLine().getStatusCode(), is(equalTo(200))); } ``` This helps with getting the base URL of the mock server, especially when a random port is used. ## Changing the directory pact files are written to By default, pact files are written to `target/pacts` (or `build/pacts` if you use Gradle), but this can be overwritten with the `pact.rootDir` system property. This property needs to be set on the test JVM as most build tools will fork a new JVM to run the tests. For Gradle, add this to your build.gradle: ```groovy test { systemProperties['pact.rootDir'] = "$buildDir/custom-pacts-directory" } ``` For maven, use the systemPropertyVariables configuration: ```xml <project> [...] <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.18</version> <configuration> <systemPropertyVariables> <pact.rootDir>some/other/directory</pact.rootDir> <buildDirectory>${project.basedir}/target</buildDirectory> [...] </systemPropertyVariables> </configuration> </plugin> </plugins> </build> [...] </project> ``` For SBT: ```scala fork in Test := true, javaOptions in Test := Seq("-Dpact.rootDir=some/other/directory") ``` ### Using `@PactDirectory` annotation You can override the directory the pacts are written in a test by adding the `@PactDirectory` annotation to the test class. ## Forcing pact files to be overwritten By default, when the pact file is written, it will be merged with any existing pact file. To force the file to be overwritten, set the Java system property `pact.writer.overwrite` to `true`. # Having values injected from provider state callbacks You can have values from the provider state callbacks be injected into most places (paths, query parameters, headers, bodies, etc.). This works by using the V3 spec generators with provider state callbacks that return values. One example of where this would be useful is API calls that require an ID which would be auto-generated by the database on the provider side, so there is no way to know what the ID would be beforehand. The following DSL methods all you to set an expression that will be parsed with the values returned from the provider states: For JSON bodies, use `valueFromProviderState`.<br/> For headers, use `headerFromProviderState`.<br/> For query parameters, use `queryParameterFromProviderState`.<br/> For paths, use `pathFromProviderState`. For example, assume that an API call is made to get the details of a user by ID. A provider state can be defined that specifies that the user must be exist, but the ID will be created when the user is created. So we can then define an expression for the path where the ID will be replaced with the value returned from the provider state callback. ```java .pathFromProviderState("/api/users/au.com.dius.pact.consumer:junit5:jar:4.3.4", "/api/users/100") ``` You can also just use the key instead of an expression: ```java .valueFromProviderState('userId', 'userId', 100) // will look value using userId as the key ``` ## Overriding the expression markers `${` and `}` (4.1.25+) You can change the markers of the expressions using the following system properties: - `pact.expressions.start` (default is `${`) - `pact.expressions.end` (default is `}`) ## Using HTTPS You can enable a HTTPS mock server by setting `https=true` on the `@PactTestFor` annotation. Note that this mock server will use a self-signed certificate, so any client code will need to accept self-signed certificates. ## Using own KeyStore You can provide your own KeyStore file to be loaded on the MockServer. In order to do so you should fulfill the properties `keyStorePath`, `keyStoreAlias`, `keyStorePassword`, `privateKeyPassword` on the `@PactTestFor` annotation. Please bear in mind you should also enable HTTPS flag. ## Using multiple providers in a test (4.2.5+) It is advisable to focus on a single interaction with each test, but you can enable multiple providers in a single test. In this case, a separate mock server will be started for each configured provider. To enable this: 1. Create a method to create the Pact for each provider annotated with the `@Pact(provider = "....")` annotation. The provider name must be set on the annotation. You can create as many of these as required, but each must have a unique provider name. 2. In the test method, use the `pactMethods` attribute on the `@PactTestFor` annotation with the names of all the methods defined in step 1. 3. Add a MockServer parameter to the test method for each provider configured in step 1 with a `@ForProvider` annotation with the name of the provider. 4. In your test method, interact with each of the mock servers passed in step 3. Note that if any mock server does not get the requests it expects, it will fail the test. For an example, see [MultiProviderTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit5/src/test/groovy/au/com/dius/pact/consumer/junit5/MultiProviderTest.groovy). ## Dealing with persistent HTTP/1.1 connections (Keep Alive) As each test will get a new mock server, connections can not be persisted between tests. HTTP clients can cache connections with HTTP/1.1, and this can cause subsequent tests to fail. See [#342](https://github.com/pact-foundation/pact-jvm/issues/342) and [#1383](https://github.com/pact-foundation/pact-jvm/issues/1383). One option (if the HTTP client supports it, Apache HTTP Client does) is to set the system property `http.keepAlive` to `false` in the test JVM. The other option is to set `pact.mockserver.addCloseHeader` to `true` to force the mock server to send a `Connection: close` header with every response (supported with Pact-JVM 4.2.7+). # Testing messages You can use Pact to test interactions with messaging systems. There are two main types of message support: asynchronous messages and synchronous request/response messages. ## Asynchronous messages Asynchronous messages are you normal type of single shot or fire and forget type messages. They are typically sent to a message queue or topic as a notification or event. With Pact tests, we will be testing that our consumer of the messages works with the messages setup as the expectations in test. This should be the message handler code that processes the actual messages that come off the message queue in production. You can use either the V3 Message Pact or the V4 Asynchronous Message interaction to test these types of interactions. For a V3 message pact example, see [AsyncMessageTest](https://github.com/pact-foundation/pact-jvm/blob/ac6a0eae0b18183f6f453eafddb89b90741ace42/consumer/junit5/src/test/java/au/com/dius/pact/consumer/junit5/AsyncMessageTest.java). For a V4 asynchronous message example, see [V4AsyncMessageTest](https://github.com/pact-foundation/pact-jvm/blob/master/consumer/junit5/src/test/groovy/au/com/dius/pact/consumer/junit5/V4AsyncMessageTest.groovy). ### Matching message metadata You can also use matching rules for the metadata associated with the message. There is a `MetadataBuilder` class to help with this. You can access it via the `withMetadata` method that takes a Java Consumer on the `MessagePactBuilder` class. For example: ```java builder.given("SomeProviderState") .expectsToReceive("a test message with metadata") .withMetadata(md -> { md.add("metadata1", "metadataValue1"); md.add("metadata2", "metadataValue2"); md.add("metadata3", 10L); md.matchRegex("partitionKey", "[A-Z]{3}\\d{2}", "ABC01"); }) .withContent(body) .toPact(); ``` ### V4 Synchronous request/response messages Synchronous request/response messages are a form of message interchange were a request message is sent to another service and one or more response messages are returned. Examples of this would be things like Websockets and gRPC. For a V4 synchronous request/response message example, see [V4AsyncMessageTest](https://github.com/pact-foundation/pact-jvm/blob/master/consumer/junit5/src/test/groovy/au/com/dius/pact/consumer/junit5/V4SyncMessageTest.groovy). # Using Pact plugins (version 4.3.0+) The `PactBuilder` consumer test builder supports using Pact plugins. Plugins are defined in the [Pact plugins project](https://github.com/pact-foundation/pact-plugins). To use plugins requires the use of Pact specification V4 Pacts. To use a plugin, first you need to let the builder know to load the plugin (using the `usingPlugin` method) and then configure the interaction based on the requirements for the plugin. Each plugin may have different requirements, so you will have to consult the plugin docs on what is required. The plugins will be loaded from the plugin directory. By default, this is `~/.pact/plugins` or the value of the `PACT_PLUGIN_DIR` environment variable. Then you need to use the `with` method that takes a Map-based data structure and passed it on to the plugin to setup the interaction. For example, if we use the CSV plugin from the plugins project, our test would look like: ```java @ExtendWith(PactConsumerTestExt.class) class CsvClientTest { /** * Setup an interaction that makes a request for a CSV report */ @Pact(consumer = "CsvClient") V4Pact pact(PactBuilder builder) { return builder // Tell the builder to load the CSV plugin .usingPlugin("csv") // Interaction we are expecting to receive .expectsToReceive("request for a report", "core/interaction/http") // Data for the interaction. This will be sent to the plugin .with(Map.of( "request.path", "/reports/report001.csv", "response.status", "200", "response.contents", Map.of( "pact:content-type", "text/csv", "csvHeaders", false, "column:1", "matching(type,'Name')", "column:2", "matching(number,100)", "column:3", "matching(datetime, 'yyyy-MM-dd','2000-01-01')" ) )) .toPact(); } /** * Test to get the CSV report */ @Test @PactTestFor(providerName = "CsvServer", pactMethod = "pact") void getCsvReport(MockServer mockServer) throws IOException { // Setup our CSV client class to point to the Pact mock server CsvClient client = new CsvClient(mockServer.getUrl()); // Fetch the CSV report List<CSVRecord> csvData = client.fetch("report001.csv", false); // Verify it is as expected assertThat(csvData.size(), is(1)); assertThat(csvData.get(0).get(0), is(equalTo("Name"))); assertThat(csvData.get(0).get(1), is(equalTo("100"))); assertThat(csvData.get(0).get(2), matchesRegex("\\d{4}-\\d{2}-\\d{2}")); } } ``` # Test Analytics We are tracking anonymous analytics to gather important usage statistics like JVM version and operating system. To disable tracking, set the 'pact_do_not_track' system property or environment variable to 'true'.
Letzte Version: 4.3.4
Freigabedatum:
Letzte Version: 5.0.2
Freigabedatum:Letzte Version: 5.11.2
Freigabedatum:
Letzte Version: 1.1.16
Freigabedatum:
ArchUnit
com.tngtech.archunit : archunit-junit5A Java architecture test library, to specify and assert architecture rules in plain Java - Module 'archunit-junit5'
Letzte Version: 0.22.0
Freigabedatum:
bootique-cayenne-junit5: JUnit 5-based helper classes for unit tests with Cayenne stack
io.bootique.cayenne : bootique-cayenne-junit5Provides JUnit 5 based helper classes for unit tests with Cayenne stack
Letzte Version: 2.0.RC1
Freigabedatum:JUnit Hierarchical Context Runner
de.bechte.junit : junit-hierarchicalcontextrunnerThis is a runner implementation that supports context hierarchies in JUnit. For more details please visit: https://github.com/bechte/junit-hierarchicalcontextrunner/wiki
Letzte Version: 4.12.2
Freigabedatum:Providence Utils : Testing / Junit 4
net.morimekta.providence : providence-testing-junit4Helper libraries for testing and comparing providence structures using junit 4.12.
Letzte Version: 2.7.0
Freigabedatum:
org-netbeans-modules-nbjunit
org.netbeans.api : org-netbeans-modules-nbjunitApache NetBeans is an integrated development environment, tooling platform, and application framework.
Letzte Version: RELEASE126
Freigabedatum:
Letzte Version: 2.0.9
Freigabedatum:Letzte Version: 20040902.070920
Freigabedatum:Letzte Version: 1.4.ga
Freigabedatum:Letzte Version: 4.0.0-RC1
Freigabedatum:Letzte Version: 1.2.1
Freigabedatum:
Letzte Version: 1.2.0
Freigabedatum:core
com.github.skjolber.mockito-rest-spring : coreREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:
Letzte Version: 3.0.2
Freigabedatum:
Letzte Version: 1.2.0
Freigabedatum:
Joala Labs JUnit
net.joala : joala-labs-junitJoala Labs is a module which provides experimental features. These experimental features might be removed at any time without notice. Typically you will find classes in here which might once make it into Joala's Public API.
Letzte Version: 1.2.1
Freigabedatum:
Letzte Version: 1.1.16
Freigabedatum:
Letzte Version: 1.1.16
Freigabedatum:
Letzte Version: 3.0.2
Freigabedatum:
Letzte Version: 1.4.3
Freigabedatum:
Arquillian TestRunner JUnit 5 Container
org.jboss.arquillian.junit5 : arquillian-junit5-containerArquillian Build Configuration
Letzte Version: 1.7.0.Alpha10
Freigabedatum:core-junit4
com.github.skjolber.mockito-rest-spring : core-junit4REST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:core-junit5
com.github.skjolber.mockito-rest-spring : core-junit5REST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:thucydides-junit
net.thucydides : thucydides-junitAn Acceptance Testing framework for web applications based on WebDriver, and integrating with JUnit and net.thucydides.easyb.
Letzte Version: 0.9.275
Freigabedatum:jetty
com.github.skjolber.mockito-rest-spring : jettyREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:
TestNG Foundation
com.nordstrom.tools : testng-foundationThis is the foundation framework for TestNG automation
Letzte Version: 3.0.6-j8
Freigabedatum:
testing-junit4
com.fnproject.fn : testing-junit4The Function Development Kit for Java makes it easy to build and deploy Java functions to Fn
Letzte Version: 1.0.145
Freigabedatum:
bootique-cayenne41-junit5: JUnit 5-based helper classes for unit tests with Cayenne stack
io.bootique.cayenne : bootique-cayenne41-junit5Provides JUnit 5 based helper classes for unit tests with Cayenne stack
Letzte Version: 2.0.RC1
Freigabedatum:Letzte Version: 3.6.100
Freigabedatum:Apache Sling JUnit Remote Tests Runners
org.apache.sling : org.apache.sling.junit.remoteUtilities to run server-side JUnit tests remotely
Letzte Version: 1.0.12
Freigabedatum:
Letzte Version: 1.0.0-M1
Freigabedatum:undertow
com.github.skjolber.mockito-rest-spring : undertowREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:tomcat
com.github.skjolber.mockito-rest-spring : tomcatREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:Letzte Version: 3.0.5
Freigabedatum:
Camunda BPM JUnit 5 Extension
org.camunda.bpm.extension : camunda-bpm-junit5Community extension to provide a process engine for JUnit 5 tests.
Letzte Version: 1.0.2
Freigabedatum:
Letzte Version: 1.6.6
Freigabedatum:
Letzte Version: 2.0.0
Freigabedatum:
chutney-junit-api
com.chutneytesting : chutney-junit-apiA junit 5 engine implementation for running glacio features.
Letzte Version: 1.4.3
Freigabedatum:junit4-tomcat
com.github.skjolber.mockito-rest-spring : junit4-tomcatREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:
chutney-junit-engine
com.chutneytesting : chutney-junit-engineA junit 5 engine implementation for running glacio features.
Letzte Version: 1.4.3
Freigabedatum:junit5-undertow
com.github.skjolber.mockito-rest-spring : junit5-undertowREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:junit4-undertow
com.github.skjolber.mockito-rest-spring : junit4-undertowREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:Letzte Version: 3.13.0
Freigabedatum:junit5-tomcat
com.github.skjolber.mockito-rest-spring : junit5-tomcatREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:junit4-jetty
com.github.skjolber.mockito-rest-spring : junit4-jettyREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:junit5-jetty
com.github.skjolber.mockito-rest-spring : junit5-jettyREST web-service mocking utility for Spring using JUnit and Mockito
Letzte Version: 1.0.3
Freigabedatum:
Arquillian TestRunner JUnit
org.jboss.arquillian : arquillian-junitJUnit Implementation for the Arquillian Project
Letzte Version: 1.0.0.Alpha5
Freigabedatum:Letzte Version: 3.11.100
Freigabedatum:
Letzte Version: 1.2.0
Freigabedatum:
org-netbeans-modules-junit
org.netbeans.modules : org-netbeans-modules-junitApache NetBeans is an integrated development environment, tooling platform, and application framework.
Letzte Version: RELEASE126
Freigabedatum:
io.tapir-test:tapir-extensions-junit5
io.tapir-test : tapir-extensions-junit5tapir JUnit5 Execution
Letzte Version: 1.3.0
Freigabedatum:
io.tapir-test:tapir-extensions-junit5-execution
io.tapir-test : tapir-extensions-junit5-executiontapir JUnit5 Execution
Letzte Version: 1.3.0
Freigabedatum:embedded-db-junit
org.zapodot : embedded-db-junitLibrary that provides a JUnit rule for setting up unit test using an embedded in-memory database (H2)
Letzte Version: 2.0.2
Freigabedatum:
PowerMock
org.powermock : powermock-module-junit4-commonPowerMock support module for all versions of JUnit 4.x.
Letzte Version: 2.0.9
Freigabedatum:
Letzte Version: 2.0.17
Freigabedatum:Glassfish JUnit Rule
com.java-adventures.junit : glassfish-junit-ruleA JUnit Rule that controls an embedded Glassfish instance.
Letzte Version: 0.3.0
Freigabedatum:
Letzte Version: 3.1.16
Freigabedatum:Letzte Version: 2.1.25
Freigabedatum:
testing-junit4
com.github.roneetshaw : testing-junit4The Function Development Kit for Java makes it easy to build and deploy Java functions to Fn
Letzte Version: 2.0.21
Freigabedatum:
JUnit Platform Suite Engine
org.junit.platform : junit-platform-suite-engineModule "junit-platform-suite-engine" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
junit-test-result-parser
org.arquillian.smart.testing : junit-test-result-parserSmart Testing is a tool that knows which tests you want to run
Letzte Version: 0.0.10
Freigabedatum:
Letzte Version: 00.07.06-RPM
Freigabedatum:
JUnit Platform Suite Commons
org.junit.platform : junit-platform-suite-commonsModule "junit-platform-suite-commons" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
Letzte Version: 1.0.0-SNAP9
Freigabedatum:
Letzte Version: 1.5.0
Freigabedatum:
bootique-jdbc-junit5-testcontainers: JUnit5 helper classes for unit tests using a Docker database
io.bootique.jdbc : bootique-jdbc-junit5-testcontainersProvides JUnit5 helper classes for unit tests using a Docker database via Testcontainers
Letzte Version: 2.0.RC1
Freigabedatum:Apache Sling JUnit Scriptable Tests Provider
org.apache.sling : org.apache.sling.junit.scriptableRegisters Sling test resources with the JUnit core so that they can be run as tests.
Letzte Version: 1.0.12
Freigabedatum:Letzte Version: 4.0.0-RC1
Freigabedatum:Letzte Version: 4.13.2
Freigabedatum:
JUnit Platform Suite (Aggregator)
org.junit.platform : junit-platform-suiteModule "junit-platform-suite" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:
Weld JUnit Extensions
org.jboss.weld : weld-junit-parentSet of JUnit extensions to enhance the testing of CDI components.
Letzte Version: 3.0.0.Final
Freigabedatum:Quarkus - JUnit 4 Mock
io.quarkus : quarkus-junit4-mockModule with some empty JUnit4 classes to allow Testcontainers to run without needing to include JUnit4 on the class path
Letzte Version: 2.7.0.CR1
Freigabedatum:cdi-test microprofile-config extension
de.hilling.junit.cdi : cdi-test-microprofilesupport microprofile-config in cdi-test
Letzte Version: 4.0.0-RC1
Freigabedatum:
Letzte Version: 1.17.0
Freigabedatum:
Letzte Version: 1.8.0
Freigabedatum:
Letzte Version: 2.0.0-alpha.7
Freigabedatum:
AssertJ-Swing - JUnit Extension
org.assertj : assertj-swing-junitJUnit-specific extension for AssertJ-Swing
Letzte Version: 3.17.1
Freigabedatum:
Letzte Version: 01.00.03-RPM
Freigabedatum:Letzte Version: 0.12
Freigabedatum:Letzte Version: 1.0.0
Freigabedatum:
Letzte Version: 0.8.21
Freigabedatum:Letzte Version: 1.10.12
Freigabedatum:
rapidpm-junit5-ext-servlet-container-api
org.rapidpm : rapidpm-junit5-ext-servlet-container-apijUnit5 Extension to start/stop Servlet Container for a test
Letzte Version: 01.00.04-RPM
Freigabedatum:
junit
au.com.dius.pact.consumer : junitpact-jvm-consumer-junit ======================= Provides a DSL and a base test class for use with Junit to build consumer tests. ## Dependency The library is available on maven central using: * group-id = `au.com.dius.pact.consumer` * artifact-id = `junit` * version-id = `4.2.9` ## Usage ### Using the base ConsumerPactTest To write a pact spec extend ConsumerPactTest. This base class defines the following four methods which must be overridden in your test class. * *providerName:* Returns the name of the API provider that Pact will mock * *consumerName:* Returns the name of the API consumer that we are testing. * *createFragment:* Returns the PactFragment containing the interactions that the test setup using the ConsumerPactBuilder DSL * *runTest:* The actual test run. It receives the URL to the mock server as a parameter. Here is an example: ```java import au.com.dius.pact.consumer.dsl.PactDslWithProvider; import au.com.dius.pact.consumer.junit.exampleclients.ConsumerClient; import au.com.dius.pact.consumer.ConsumerPactTest; import au.com.dius.pact.model.PactFragment; import org.junit.Assert; import java.io.IOException; import java.util.HashMap; import java.util.Map; import static org.junit.Assert.assertEquals; public class ExampleJavaConsumerPactTest extends ConsumerPactTest { @Override protected RequestResponsePact createFragment(PactDslWithProvider builder) { Map<String, String> headers = new HashMap<String, String>(); headers.put("testreqheader", "testreqheadervalue"); return builder .given("test state") // NOTE: Using provider states are optional, you can leave it out .uponReceiving("ExampleJavaConsumerPactTest test interaction") .path("/") .method("GET") .headers(headers) .willRespondWith() .status(200) .headers(headers) .body("{\"responsetest\": true, \"name\": \"harry\"}") .given("test state 2") // NOTE: Using provider states are optional, you can leave it out .uponReceiving("ExampleJavaConsumerPactTest second test interaction") .method("OPTIONS") .headers(headers) .path("/second") .body("") .willRespondWith() .status(200) .headers(headers) .body("") .toPact(); } @Override protected String providerName() { return "test_provider"; } @Override protected String consumerName() { return "test_consumer"; } @Override protected void runTest(MockServer mockServer, PactTestExecutionContext context) throws IOException { Assert.assertEquals(new ConsumerClient(mockServer.getUrl()).options("/second"), 200); Map expectedResponse = new HashMap(); expectedResponse.put("responsetest", true); expectedResponse.put("name", "harry"); assertEquals(new ConsumerClient(mockServer.getUrl()).getAsMap("/", ""), expectedResponse); assertEquals(new ConsumerClient(mockServer.getUrl()).options("/second"), 200); } } ``` ### Using the Pact JUnit Rule Thanks to [@warmuuh](https://github.com/warmuuh) we have a JUnit rule that simplifies running Pact consumer tests. To use it, create a test class and then add the rule: #### 1. Add the Pact Rule to your test class to represent your provider. ```java @Rule public PactProviderRule mockProvider = new PactProviderRule("test_provider", "localhost", 8080, this); ``` The hostname and port are optional. If left out, it will default to 127.0.0.1 and a random available port. You can get the URL and port from the pact provider rule. #### 2. Annotate a method with Pact that returns a pact fragment for the provider and consumer ```java @Pact(provider="test_provider", consumer="test_consumer") public RequestResponsePact createPact(PactDslWithProvider builder) { return builder .given("test state") .uponReceiving("ExampleJavaConsumerPactRuleTest test interaction") .path("/") .method("GET") .willRespondWith() .status(200) .body("{\"responsetest\": true}") .toPact(); } ``` You can leave the provider name out. It will then use the provider name of the first mock provider found. I.e., ```java @Pact(consumer="test_consumer") // will default to the provider name from mockProvider public RequestResponsePact createFragment(PactDslWithProvider builder) { return builder .given("test state") .uponReceiving("ExampleJavaConsumerPactRuleTest test interaction") .path("/") .method("GET") .willRespondWith() .status(200) .body("{\"responsetest\": true}") .toPact(); } ``` #### 3. Annotate your test method with PactVerification to have it run in the context of the mock server setup with the appropriate pact from step 1 and 2 ```java @Test @PactVerification("test_provider") public void runTest() { Map expectedResponse = new HashMap(); expectedResponse.put("responsetest", true); assertEquals(new ConsumerClient(mockProvider.getUrl()).get("/"), expectedResponse); } ``` You can leave the provider name out. It will then use the provider name of the first mock provider found. I.e., ```java @Test @PactVerification public void runTest() { // This will run against mockProvider Map expectedResponse = new HashMap(); expectedResponse.put("responsetest", true); assertEquals(new ConsumerClient("http://localhost:8080").get("/"), expectedResponse); } ``` For an example, have a look at [ExampleJavaConsumerPactRuleTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit/src/test/java/au/com/dius/pact/consumer/junit/examples/ExampleJavaConsumerPactRuleTest.java) ### Requiring a test with multiple providers The Pact Rule can be used to test with multiple providers. Just add a rule to the test class for each provider, and then include all the providers required in the `@PactVerification` annotation. For an example, look at [PactMultiProviderTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit/src/test/java/au/com/dius/pact/consumer/junit/pactproviderrule/PactMultiProviderTest.java). Note that if more than one provider fails verification for the same test, you will only receive a failure for one of them. Also, to have multiple tests in the same test class, the providers must be setup with random ports (i.e. don't specify a hostname and port). Also, if the provider name is left out of any of the annotations, the first one found will be used (which may not be the first one defined). ### Requiring the mock server to run with HTTPS The mock server can be started running with HTTPS using a self-signed certificate instead of HTTP. To enable this set the `https` parameter to `true`. E.g.: ```java @Rule public PactProviderRule mockTestProvider = new PactProviderRule("test_provider", "localhost", 8443, true, PactSpecVersion.V2, this); // ^^^^ ``` For an example test doing this, see [PactProviderHttpsTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit/src/test/java/au/com/dius/pact/consumer/junit/pactproviderrule/PactProviderHttpsTest.java). **NOTE:** The provider will start handling HTTPS requests using a self-signed certificate. Most HTTP clients will not accept connections to a self-signed server as the certificate is untrusted. You may need to enable insecure HTTPS with your client for this test to work. For an example of how to enable insecure HTTPS client connections with Apache Http Client, have a look at [InsecureHttpsRequest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit/src/test/java/org/apache/http/client/fluent/InsecureHttpsRequest.java). ### Requiring the mock server to run with HTTPS with a keystore The mock server can be started running with HTTPS using a keystore. To enable this set the `https` parameter to `true`, set the keystore path/file, and the keystore's password. E.g.: ```java @Rule public PactProviderRule mockTestProvider = new PactProviderRule("test_provider", "localhost", 8443, true, "/path/to/your/keystore.jks", "your-keystore-password", PactSpecVersion.V2, this); ``` For an example test doing this, see [PactProviderHttpsKeystoreTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit/src/test/java/au/com/dius/pact/consumer/junit/pactproviderrule/PactProviderHttpsKeystoreTest.java). ### Setting default expected request and response values If you have a lot of tests that may share some values (like headers), you can setup default values that will be applied to all the expected requests and responses for the tests. To do this, you need to create a method that takes single parameter of the appropriate type (`PactDslRequestWithoutPath` or `PactDslResponse`) and annotate it with the default marker annotation (`@DefaultRequestValues` or `@DefaultResponseValues`). For example: ```java @DefaultRequestValues public void defaultRequestValues(PactDslRequestWithoutPath request) { Map<String, String> headers = new HashMap<String, String>(); headers.put("testreqheader", "testreqheadervalue"); request.headers(headers); } @DefaultResponseValues public void defaultResponseValues(PactDslResponse response) { Map<String, String> headers = new HashMap<String, String>(); headers.put("testresheader", "testresheadervalue"); response.headers(headers); } ``` For an example test that uses these, have a look at [PactProviderWithMultipleFragmentsTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit/src/test/java/au/com/dius/pact/consumer/junit/pactproviderrule/PactProviderWithMultipleFragmentsTest.java) ### Note on HTTP clients and persistent connections Some HTTP clients may keep the connection open, based on the live connections settings or if they use a connection cache. This could cause your tests to fail if the client you are testing lives longer than an individual test, as the mock server will be started and shutdown for each test. This will result in the HTTP client connection cache having invalid connections. For an example of this where the there was a failure for every second test, see [Issue #342](https://github.com/DiUS/pact-jvm/issues/342). ### Using the Pact DSL directly Sometimes it is not convenient to use the ConsumerPactTest as it only allows one test per test class. The DSL can be used directly in this case. Example: ```java import au.com.dius.pact.consumer.ConsumerPactBuilder; import au.com.dius.pact.consumer.PactVerificationResult; import au.com.dius.pact.consumer.junit.exampleclients.ProviderClient; import au.com.dius.pact.model.MockProviderConfig; import au.com.dius.pact.model.RequestResponsePact; import org.junit.Test; import java.io.IOException; import java.util.HashMap; import java.util.Map; import static au.com.dius.pact.consumer.ConsumerPactRunnerKt.runConsumerTest; import static org.junit.Assert.assertEquals; /** * Sometimes it is not convenient to use the ConsumerPactTest as it only allows one test per test class. * The DSL can be used directly in this case. */ public class DirectDSLConsumerPactTest { @Test public void testPact() { RequestResponsePact pact = ConsumerPactBuilder .consumer("Some Consumer") .hasPactWith("Some Provider") .uponReceiving("a request to say Hello") .path("/hello") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") .toPact(); MockProviderConfig config = MockProviderConfig.createDefault(); PactVerificationResult result = runConsumerTest(pact, config, (mockServer, context) -> { Map expectedResponse = new HashMap(); expectedResponse.put("hello", "harry"); try { assertEquals(new ProviderClient(mockServer.getUrl()).hello("{\"name\": \"harry\"}"), expectedResponse); } catch (IOException e) { throw new RuntimeException(e); } }); if (result instanceof PactVerificationResult.Error) { throw new RuntimeException(((PactVerificationResult.Error)result).getError()); } assertEquals(PactVerificationResult.Ok.INSTANCE, result); } } ``` ### The Pact JUnit DSL The DSL has the following pattern: ```java .consumer("Some Consumer") .hasPactWith("Some Provider") .given("a certain state on the provider") .uponReceiving("a request for something") .path("/hello") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") .uponReceiving("another request for something") .path("/hello") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") . . . .toPact() ``` You can define as many interactions as required. Each interaction starts with `uponReceiving` followed by `willRespondWith`. The test state setup with `given` is a mechanism to describe what the state of the provider should be in before the provider is verified. It is only recorded in the consumer tests and used by the provider verification tasks. ### Building JSON bodies with PactDslJsonBody DSL **NOTE:** If you are using Java 8, there is [an updated DSL for consumer tests](/consumer/java8/README.md). The body method of the ConsumerPactBuilder can accept a PactDslJsonBody, which can construct a JSON body as well as define regex and type matchers. For example: ```java PactDslJsonBody body = new PactDslJsonBody() .stringType("name") .booleanType("happy") .hexValue("hexCode") .id() .ipAddress("localAddress") .numberValue("age", 100) .timestamp(); ``` #### DSL Matching methods The following matching methods are provided with the DSL. In most cases, they take an optional value parameter which will be used to generate example values (i.e. when returning a mock response). If no example value is given a random one will be generated. | method | description | |--------|-------------| | string, stringValue | Match a string value (using string equality) | | number, numberValue | Match a number value (using Number.equals)\* | | booleanValue | Match a boolean value (using equality) | | stringType | Will match all Strings | | numberType | Will match all numbers\* | | integerType | Will match all numbers that are integers (both ints and longs)\* | | decimalType | Will match all real numbers (floating point and decimal)\* | | booleanType | Will match all boolean values (true and false) | | stringMatcher | Will match strings using the provided regular expression | | timestamp | Will match string containing timestamps. If a timestamp format is not given, will match an ISO timestamp format | | date | Will match string containing dates. If a date format is not given, will match an ISO date format | | time | Will match string containing times. If a time format is not given, will match an ISO time format | | ipAddress | Will match string containing IP4 formatted address. | | id | Will match all numbers by type | | hexValue | Will match all hexadecimal encoded strings | | uuid | Will match strings containing UUIDs | | includesStr | Will match strings containing the provided string | | equalsTo | Will match using equals | | matchUrl | Defines a matcher for URLs, given the base URL path and a sequence of path fragments. The path fragments could be strings or regular expression matchers | | nullValue | Matches the JSON Null value | _\* Note:_ JSON only supports double precision floating point values. Depending on the language implementation, they may be parsed as integer, floating point or decimal numbers. #### Ensuring all items in a list match an example Lots of the time you might not know the number of items that will be in a list, but you want to ensure that the list has a minimum or maximum size and that each item in the list matches a given example. You can do this with the `arrayLike`, `minArrayLike` and `maxArrayLike` functions. | function | description | |----------|-------------| | `eachLike` | Ensure that each item in the list matches the provided example | | `maxArrayLike` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max | | `minArrayLike` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min | For example: ```java DslPart body = new PactDslJsonBody() .minArrayLike("users", 1) .id() .stringType("name") .closeObject() .closeArray(); ``` This will ensure that the users list is never empty and that each user has an identifier that is a number and a name that is a string. You can specify the number of example items to generate in the array. The default is 1. ```java DslPart body = new PactDslJsonBody() .minArrayLike("users", 1, 2) .id() .stringType("name") .closeObject() .closeArray(); ``` #### Ignoring the list order (V4 specification) If the order of the list items is not known, you can use the `unorderedArray` matcher functions. These will match the actual list against the expected one, except will match the items in any order. | function | description | |----------|-------------| | `unorderedArray` | Ensure that the list matches the provided example, ignoring the order | | `unorderedMinArray` | Ensure that the list matches the provided example and the list is not smaller than the provided min | | `unorderedMaxArray` | Ensure that the list matches the provided example and the list is no bigger than the provided max | | `unorderedMinMaxArray` | Ensure that the list matches the provided example and the list is constrained to the provided min and max | #### Array contains matcher (V4 specification) The array contains matcher functions allow you to match the actual list against a list of required variants. These work by matching each item against the variants, and the matching succeeds if each variant matches at least one item. Order of items in the list is not important. The variants can have a totally different structure, and can have their own matching rules to apply. For an example of how these can be used to match a hypermedia format like Siren, see [Example Pact + Siren project](https://github.com/pactflow/example-siren). | function | description | |----------|-------------| | `arrayContaining` | Matches the items in an array against a number of variants. Matching is successful if each variant occurs once in the array. Variants may be objects containing matching rules. | ```java .arrayContaining("actions") .object() .stringValue("name", "update") .stringValue("method", "PUT") .matchUrl("href", "http://localhost:9000", "orders", regex("\\d+", "1234")) .closeObject() .object() .stringValue("name", "delete") .stringValue("method", "DELETE") .matchUrl("href", "http://localhost:9000", "orders", regex("\\d+", "1234")) .closeObject() .closeArray() ``` #### Root level arrays that match all items If the root of the body is an array, you can create PactDslJsonArray classes with the following methods: | function | description | |----------|-------------| | `arrayEachLike` | Ensure that each item in the list matches the provided example | | `arrayMinLike` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max | | `arrayMaxLike` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min | For example: ```java PactDslJsonArray.arrayEachLike() .date("clearedDate", "mm/dd/yyyy", date) .stringType("status", "STATUS") .decimalType("amount", 100.0) .closeObject() ``` This will then match a body like: ```json [ { "clearedDate" : "07/22/2015", "status" : "C", "amount" : 15.0 }, { "clearedDate" : "07/22/2015", "status" : "C", "amount" : 15.0 }, { "clearedDate" : "07/22/2015", "status" : "C", "amount" : 15.0 } ] ``` You can specify the number of example items to generate in the array. The default is 1. #### Matching JSON values at the root For cases where you are expecting basic JSON values (strings, numbers, booleans and null) at the root level of the body and need to use matchers, you can use the `PactDslJsonRootValue` class. It has all the DSL matching methods for basic values that you can use. For example: ```java .consumer("Some Consumer") .hasPactWith("Some Provider") .uponReceiving("a request for a basic JSON value") .path("/hello") .willRespondWith() .status(200) .body(PactDslJsonRootValue.integerType()) ``` #### Matching any key in a map The DSL has been extended for cases where the keys in a map are IDs. For an example of this, see [#313](https://github.com/DiUS/pact-jvm/issues/313). In this case you can use the `eachKeyLike` method, which takes an example key as a parameter. For example: ```java DslPart body = new PactDslJsonBody() .object("one") .eachKeyLike("001", PactDslJsonRootValue.id(12345L)) // key like an id mapped to a matcher .closeObject() .object("two") .eachKeyLike("001-A") // key like an id where the value is matched by the following example .stringType("description", "Some Description") .closeObject() .closeObject() .object("three") .eachKeyMappedToAnArrayLike("001") // key like an id mapped to an array where each item is matched by the following example .id("someId", 23456L) .closeObject() .closeArray() .closeObject(); ``` For an example, have a look at [WildcardKeysTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit/src/test/java/au/com/dius/pact/consumer/junit/WildcardKeysTest.java). #### Combining matching rules with AND/OR Matching rules can be combined with AND/OR. There are two methods available on the DSL for this. For example: ```java DslPart body = new PactDslJsonBody() .numberValue("valueA", 100) .and("valueB","AB", PM.includesStr("A"), PM.includesStr("B")) // Must match both matching rules .or("valueC", null, PM.date(), PM.nullValue()) // will match either a valid date or a null value ``` The `and` and `or` methods take a variable number of matchers (varargs). ### Overriding the handling of a body data type **NOTE: version 4.1.3+** By default, bodies will be handled based on their content types. For binary contents, the bodies will be base64 encoded when written to the Pact file and then decoded again when the file is loaded. You can change this with an override property: `pact.content_type.override.<TYPE>.<SUBTYPE>=text|binary|json`. For instance, setting `pact.content_type.override.application.pdf=text` will treat PDF bodies as a text type and not encode/decode them. ### Matching on paths You can use regular expressions to match incoming requests. The DSL has a `matchPath` method for this. You can provide a real path as a second value to use when generating requests, and if you leave it out it will generate a random one from the regular expression. For example: ```java .given("test state") .uponReceiving("a test interaction") .matchPath("/transaction/[0-9]+") // or .matchPath("/transaction/[0-9]+", "/transaction/1234567890") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") ``` ### Matching on headers You can use regular expressions to match request and response headers. The DSL has a `matchHeader` method for this. You can provide an example header value to use when generating requests and responses, and if you leave it out it will generate a random one from the regular expression. For example: ```java .given("test state") .uponReceiving("a test interaction") .path("/hello") .method("POST") .matchHeader("testreqheader", "test.*value") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") .matchHeader("Location", ".*/hello/[0-9]+", "/hello/1234") ``` ### Matching on query parameters You can use regular expressions to match request query parameters. The DSL has a `matchQuery` method for this. You can provide an example value to use when generating requests, and if you leave it out it will generate a random one from the regular expression. For example: ```java .given("test state") .uponReceiving("a test interaction") .path("/hello") .method("POST") .matchQuery("a", "\\d+", "100") .matchQuery("b", "[A-Z]", "X") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") ``` ## Debugging pact failures When the test runs, Pact will start a mock provider that will listen for requests and match them against the expectations you setup in `createFragment`. If the request does not match, it will return a 500 error response. Each request received and the generated response is logged using [SLF4J](http://www.slf4j.org/). Just enable debug level logging for au.com.dius.pact.consumer.UnfilteredMockProvider. Most failures tend to be mismatched headers or bodies. ## Changing the directory pact files are written to By default, pact files are written to `target/pacts` (or `build/pacts` if you use Gradle), but this can be overwritten with the `pact.rootDir` system property. This property needs to be set on the test JVM as most build tools will fork a new JVM to run the tests. For Gradle, add this to your build.gradle: ```groovy test { systemProperties['pact.rootDir'] = "$buildDir/custom-pacts-directory" } ``` For maven, use the systemPropertyVariables configuration: ```xml <project> [...] <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.18</version> <configuration> <systemPropertyVariables> <pact.rootDir>some/other/directory</pact.rootDir> <buildDirectory>${project.basedir}/target</buildDirectory> [...] </systemPropertyVariables> </configuration> </plugin> </plugins> </build> [...] </project> ``` For SBT: ```scala fork in Test := true, javaOptions in Test := Seq("-Dpact.rootDir=some/other/directory") ``` ### Using `@PactDirectory` annotation You can override the directory the pacts are written in a test by adding the `@PactDirectory` annotation to the test class. ## Forcing pact files to be overwritten (3.6.5+) By default, when the pact file is written, it will be merged with any existing pact file. To force the file to be overwritten, set the Java system property `pact.writer.overwrite` to `true`. # Publishing your pact files to a pact broker If you use Gradle, you can use the [pact Gradle plugin](/provider/gradle/README.md#publishing-pact-files-to-a-pact-broker) to publish your pact files. # Pact Specification V3 Version 3 of the pact specification changes the format of pact files in the following ways: * Query parameters are stored in a map form and are un-encoded (see [#66](https://github.com/DiUS/pact-jvm/issues/66) and [#97](https://github.com/DiUS/pact-jvm/issues/97) for information on what this can cause). * Introduces a new message pact format for testing interactions via a message queue. * Multiple provider states can be defined with data parameters. ## Generating V2 spec pact files To have your consumer tests generate V2 format pacts, you can set the specification version to V2. If you're using the `ConsumerPactTest` base class, you can override the `getSpecificationVersion` method. For example: ```java @Override protected PactSpecVersion getSpecificationVersion() { return PactSpecVersion.V2; } ``` If you are using the `PactProviderRule`, you can pass the version into the constructor for the rule. ```java @Rule public PactProviderRule mockTestProvider = new PactProviderRule("test_provider", PactSpecVersion.V2, this); ``` ## Consumer test for a message consumer For testing a consumer of messages from a message queue, the `MessagePactProviderRule` rule class works in much the same way as the `PactProviderRule` class for Request-Response interactions, but will generate a V3 format message pact file. For an example, look at [ExampleMessageConsumerTest](https://github.com/DiUS/pact-jvm/blob/master/consumer/junit/src/test/java/au/com/dius/pact/consumer/junit/v3/ExampleMessageConsumerTest.java) ### Matching message metadata You can also use matching rules for the metadata associated with the message. There is a `MetadataBuilder` class to help with this. You can access it via the `withMetadata` method that takes a Java Consumer on the `MessagePactBuilder` class. For example: ```java builder.given("SomeProviderState") .expectsToReceive("a test message with metadata") .withMetadata(md -> { md.add("metadata1", "metadataValue1"); md.add("metadata2", "metadataValue2"); md.add("metadata3", 10L); md.matchRegex("partitionKey", "[A-Z]{3}\\d{2}", "ABC01"); }) .withContent(body) .toPact(); ``` # Having values injected from provider state callbacks (3.6.11+) You can have values from the provider state callbacks be injected into most places (paths, query parameters, headers, bodies, etc.). This works by using the V3 spec generators with provider state callbacks that return values. One example of where this would be useful is API calls that require an ID which would be auto-generated by the database on the provider side, so there is no way to know what the ID would be beforehand. The following DSL methods all you to set an expression that will be parsed with the values returned from the provider states: For JSON bodies, use `valueFromProviderState`.<br/> For headers, use `headerFromProviderState`.<br/> For query parameters, use `queryParameterFromProviderState`.<br/> For paths, use `pathFromProviderState`. For example, assume that an API call is made to get the details of a user by ID. A provider state can be defined that specifies that the user must be exist, but the ID will be created when the user is created. So we can then define an expression for the path where the ID will be replaced with the value returned from the provider state callback. ```java .pathFromProviderState("/api/users/au.com.dius.pact.consumer:junit:jar:4.3.4", "/api/users/100") ``` You can also just use the key instead of an expression: ```java .valueFromProviderState('userId', 'userId', 100) // will look value using userId as the key ``` ## Overriding the expression markers `${` and `}` (4.1.25+) You can change the markers of the expressions using the following system properties: - `pact.expressions.start` (default is `${`) - `pact.expressions.end` (default is `}`) ## Dealing with persistent HTTP/1.1 connections (Keep Alive) As each test will get a new mock server, connections can not be persisted between tests. HTTP clients can cache connections with HTTP/1.1, and this can cause subsequent tests to fail. See [#342](https://github.com/pact-foundation/pact-jvm/issues/342) and [#1383](https://github.com/pact-foundation/pact-jvm/issues/1383). One option (if the HTTP client supports it, Apache HTTP Client does) is to set the system property `http.keepAlive` to `false` in the test JVM. The other option is to set `pact.mockserver.addCloseHeader` to `true` to force the mock server to send a `Connection: close` header with every response (supported with Pact-JVM 4.2.7+). # Test Analytics We are tracking anonymous analytics to gather important usage statistics like JVM version and operating system. To disable tracking, set the 'pact_do_not_track' system property or environment variable to 'true'.
Letzte Version: 4.3.4
Freigabedatum:JUnit Viewer
org.apache.isis.viewer : junitRoot POM for core framework, the viewers, and the runtime implementations. Defines standard build process, as well as standard set of 3rd party dependencies (eg for testing and logging frameworks).
Letzte Version: 0.2.0-incubating
Freigabedatum:
testIT | TestUtils - Mockito
info.novatec.testit : testutils-mockitoA collection of test-related utility libraries.
Letzte Version: 0.3.4
Freigabedatum:Letzte Version: 0.1.0
Freigabedatum:
Letzte Version: 5.0.0-ALPHA
Freigabedatum:JUnit Jupiter Causal-Cluster-Testcontainer Extension
eu.michael-simons.neo4j : junit-jupiter-causal-cluster-testcontainer-extensionProvides a JUnit Jupiter extension that creates Neo4j causal clusters on demand.
Letzte Version: 2022.0.0
Freigabedatum:
tourniquet-core
io.tourniquet.junit : tourniquet-coreAPI for tourniquet entities, providing common classes and interfaces used throughout tourniquet
Letzte Version: 0.4.8
Freigabedatum:
JUnit 4 Core
org.testifyproject.junit4 : junit4-coreA module that contains base Testify JUnit 4 TestRunner implementation and a JUnit test runner for running unit tests
Letzte Version: 1.0.6
Freigabedatum:
testcontainers-concord-junit4
ca.ibodrov.concord : testcontainers-concord-junit4Allows running Concord in JUnit 5 tests using Testcontainers
Letzte Version: 0.0.40
Freigabedatum:
jQAssistant JUnit Plugin
com.buschmais.jqassistant.plugin : junitPlugin for jQAssistant to be able to scan and to analyze JUnit related artifacts.
Letzte Version: 1.11.1
Freigabedatum:specsy-junit
org.specsy : specsy-junitSpecsy is a BDD-style unit-level testing framework for Java/Scala/Groovy. It safely isolates mutable state and supports writing self-documenting tests/specifications.
Letzte Version: 2.3.3
Freigabedatum:
Letzte Version: 5.4.3
Freigabedatum:SodaTest JUnit Integration
org.sodatest : sodatest-junitcontains the JUnitSodaTestLauncherTestBase which you can create subclasses of in your own test tree to easily get JUnit running your SodaTests.
Letzte Version: 0.2.1
Freigabedatum:mars-junit
com.github.yuyenews : mars-junitSonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 2.1.5
Freigabedatum:
Letzte Version: 5.1.1
Freigabedatum:
Spek JUnit Platform Engine
org.jetbrains.spek : spek-junit-platform-engineSpek TestEngine for the JUnit Platform
Letzte Version: 1.1.5
Freigabedatum:
Quarkus - Test framework - JUnit 5 - Mockito
io.quarkus : quarkus-junit5-mockitoBuild parent to bring in required dependencies
Letzte Version: 2.7.0.CR1
Freigabedatum:
Letzte Version: 1.1.8
Freigabedatum:Letzte Version: 3.3.0
Freigabedatum:Apache Sling Testing OSGi Mock JUnit 5
org.apache.sling : org.apache.sling.testing.osgi-mock.junit5Mock implementation of selected OSGi APIs.
Letzte Version: 3.2.2
Freigabedatum:
Letzte Version: 2.0.9
Freigabedatum:JUnit Extensions
io.github.glytching : junit-extensionsJUnit Jupiter extensions, providing 'JUnit5 replacements' for some common JUnit4 Rules.
Letzte Version: 2.5.0
Freigabedatum:Letzte Version: 1.0.0
Freigabedatum:Letzte Version: 1.1
Freigabedatum:Letzte Version: 0.0.22
Freigabedatum:sulky-junit
de.huxhorn.sulky : de.huxhorn.sulky.junitThis file is part of the sulky modules. It contains JUnit utilities.
Letzte Version: 8.3.0
Freigabedatum:
osgi.enroute.junit.wrapper
org.osgi : osgi.enroute.junit.wrapperJUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. This bundle wraps JUnit as is and exports all packages with the bundle version since JUnit has not understood package versioning, nor semantic versioning. We also make imports optional since it has
Letzte Version: 4.12.0
Freigabedatum:embedded-db-junit-jupiter
org.zapodot : embedded-db-junit-jupiterLibrary that provides a JUnit rule for setting up unit test using an embedded in-memory database (H2)
Letzte Version: 2.0.2
Freigabedatum:embedded-db-junit-liquibase
org.zapodot : embedded-db-junit-liquibaseLibrary that provides a JUnit rule for setting up unit test using an embedded in-memory database (H2)
Letzte Version: 2.0.2
Freigabedatum:
Letzte Version: 3.2.0.0-M2
Freigabedatum:dexmaker mockito
com.google.dexmaker : dexmaker-mockitoSonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 1.2
Freigabedatum:Letzte Version: 1.1
Freigabedatum:
Arquillian TestRunner TestNG Standalone
org.jboss.arquillian.testng : arquillian-testng-standaloneTestNG Standalone Implementation for the Arquillian Project
Letzte Version: 1.7.0.Alpha10
Freigabedatum:Cucumber-JVM: JUnit
com.github.slaout.fork.info.cukesthreads : cucumber-junitSonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 1.2.4
Freigabedatum:
Flink : Test utils : Junit
org.apache.flink : flink-test-utils-junitThe Apache Software Foundation provides support for the Apache community of open-source software projects. The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users.
Letzte Version: 1.14.3
Freigabedatum:Camunda BPM Process Test Coverage JUnit5
org.camunda.bpm.extension : camunda-bpm-process-test-coverage-junit5Helper library to visualize and assert which parts of a BPMN process have been covered by a test.
Letzte Version: 1.0.2
Freigabedatum:
Letzte Version: 1.3.0
Freigabedatum:
eu.coldrye.junit:junit-common
eu.coldrye.junit : junit-commonCommonly used code for junit-testing projects
Letzte Version: 1.2.0
Freigabedatum:
Letzte Version: 0.4.3
Freigabedatum:
PowerMock
org.powermock : powermock-module-junit4-legacyPowerMock support module for JUnit 4.0-4.3.
Letzte Version: 2.0.9
Freigabedatum:Axon Testing - JGiven Support for JUnit5
io.holixon.axon.testing : axon-testing-jgiven-junit5A set of tools to write even more effective tests for systems built with Axon Framework.
Letzte Version: 0.1.0
Freigabedatum:Axon Testing - JGiven Support for JUnit4
io.holixon.axon.testing : axon-testing-jgiven-junitA set of tools to write even more effective tests for systems built with Axon Framework.
Letzte Version: 0.1.0
Freigabedatum:Letzte Version: 0.14
Freigabedatum:Camunda BPM Process Test Coverage JUnit4
org.camunda.bpm.extension : camunda-bpm-process-test-coverage-junit4Helper library to visualize and assert which parts of a BPMN process have been covered by a test.
Letzte Version: 1.0.2
Freigabedatum:junit-servers-core
com.github.mjeanroy : junit-servers-coreAdd Embedded Server to your junit tests case.
Letzte Version: 2.1.0
Freigabedatum:
bootique-jdbc-junit5: Common JUnit5-based helper classes for tests that require a database
io.bootique.jdbc : bootique-jdbc-junit5Provides common abstarct JUnit5-based helper classes for tests that require a database. Users should import its "submodules" - "bootique-jdbc-junit5-derby" and "bootique-jdbc-junit5-testcontainers"
Letzte Version: 2.0.RC1
Freigabedatum:
Letzte Version: 1.17.0
Freigabedatum:
Letzte Version: 4.2.0
Freigabedatum:
Letzte Version: 4.2.0
Freigabedatum:
Letzte Version: 2.0.0
Freigabedatum:
Letzte Version: 1.17.0
Freigabedatum:
jQAssistant TestNG Plugin
com.buschmais.jqassistant.plugin : testngPlugin for jQAssistant to be able to scan and to analyze TestNG related artifacts.
Letzte Version: 1.11.1
Freigabedatum:Cucumber-JVM: TestNG
com.github.slaout.fork.info.cukesthreads : cucumber-testngSonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 1.2.4
Freigabedatum:Logback Appender for TestNG
com.github.sbabcoc : logback-testngThis appender enables users to direct the Logback output from TestNG tests to the TestNG Reporter.
Letzte Version: 1.3.4
Freigabedatum:
jqassistant.plugin.testng
com.buschmais.jqassistant.plugin : jqassistant.plugin.testngFramework for structural analysis of Java applications.
Letzte Version: 1.1.4
Freigabedatum:Vert.x JUnit 5 RxJava2 support
io.vertx : vertx-junit5-rx-java2Sonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 4.2.4
Freigabedatum:
Letzte Version: 0.4.3
Freigabedatum:Letzte Version: 6.0.3
Freigabedatum:JGit - JUnit Utility Classes
com.madgag : org.eclipse.jgit.junitUtility classes to support JUnit testing of JGit applications.
Letzte Version: 3.4.0.1.1-UNOFFICIAL-ROBERTO-RELEASE
Freigabedatum:
weld-junit-common
org.jboss.weld : weld-junit-commonSet of JUnit extensions to enhance the testing of CDI components.
Letzte Version: 3.0.0.Final
Freigabedatum:zuchini-junit
org.zuchini : zuchini-junitAn alternative implementation of cucumber for the jvm based on antlr and junit
Letzte Version: 0.4.0
Freigabedatum:
Letzte Version: 1.8.0
Freigabedatum:
Letzte Version: 0.15
Freigabedatum:JGit - JUnit Utility Classes
org.openl.jgit : org.eclipse.jgit.junitUtility classes to support JUnit testing of JGit applications.
Letzte Version: 6.0.0.202111291000-r
Freigabedatum:
Letzte Version: 0.4.3
Freigabedatum:
Letzte Version: 5.0.6
Freigabedatum:
S3Mock - Testsupport - JUnit5
com.adobe.testing : s3mock-junit5S3 mock implementation to be used for hermetic testing
Letzte Version: 2.3.3
Freigabedatum:junit-testcontainer-commons
io.appform.testcontainer : junit-testcontainer-commonsEmbedded testcontainers for data stores
Letzte Version: 1.0.6
Freigabedatum:
Component Runtime :: Testing :: JUnit Base
org.talend.sdk.component : component-runtime-junit-baseSome JUnit utilities, reused accross the other testing module. IMPORTANT: this module must not depend on the runtime/framework.
Letzte Version: 1.41.0
Freigabedatum:Vert.x JUnit 5 RxJava support
io.vertx : vertx-junit5-rx-javaSonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 4.2.4
Freigabedatum:Letzte Version: 6.0.3
Freigabedatum:JUnit Foundation
com.nordstrom.tools : junit-foundationThis is the foundation framework for JUnit automation
Letzte Version: 15.3.4
Freigabedatum:Letzte Version: 2.9.ga
Freigabedatum:
Letzte Version: 3.3.0.0-SNAP3
Freigabedatum:
Letzte Version: 1.17.0
Freigabedatum:Letzte Version: 0.1.47
Freigabedatum:
docker-compose-junit-jupiter
com.palantir.docker.compose : docker-compose-junit-jupiterPalantir open source project
Letzte Version: 1.7.0
Freigabedatum:
Letzte Version: 3.3.0.0-SNAP2
Freigabedatum:
Letzte Version: 1.0.0-SNAP9
Freigabedatum:
JUnit Platform Console Standalone
org.junit.platform : junit-platform-console-standaloneModule "junit-platform-console-standalone" of JUnit 5.
Letzte Version: 1.8.2
Freigabedatum:Letzte Version: 4.7-201002241900
Freigabedatum:Testing utilities: Junit 5 Framework
com.torodb.testing : core-junit5This is a aggregation and parent pom used by ToroDB testing utility projects.
Letzte Version: 1.0.0
Freigabedatum:
Letzte Version: 1.8.0
Freigabedatum:
Dekorate :: Testing :: Core
io.dekorate : core-junitA collection of annotations and processors for Kubernetes
Letzte Version: 2.8.0
Freigabedatum:Letzte Version: 3.3.0-v20070606-0010
Freigabedatum:
jqassistant.plugin.junit4
com.buschmais.jqassistant.plugin : jqassistant.plugin.junit4Framework for structural analysis of Java applications.
Letzte Version: 1.0.0-M4
Freigabedatum:JBehave JUnit Runner
com.github.valfirst : jbehave-junit-runnerLibrary designed to make JBehave stories & scenarios show up in the JUnit view in IDEs supportting custom test runners
Letzte Version: 2.3.0
Freigabedatum:
Letzte Version: 1.7.4
Freigabedatum:Letzte Version: 3.3.0-v20070606-0010
Freigabedatum:
Letzte Version: 3.3.0.0-SNAP2
Freigabedatum:
Letzte Version: 1.0.1
Freigabedatum:Letzte Version: 1.2.0
Freigabedatum:
pact-jvm-provider-junit_2.12
au.com.dius : pact-jvm-provider-junit_2.12# Pact junit runner ## Overview Library provides ability to play contract tests against a provider service in JUnit fashionable way. Supports: - Out-of-the-box convenient ways to load pacts - Easy way to change assertion strategy - **org.junit.BeforeClass**, **org.junit.AfterClass** and **org.junit.ClassRule** JUnit annotations, that will be run once - before/after whole contract test suite. - **org.junit.Before**, **org.junit.After** and **org.junit.Rule** JUnit annotations, that will be run before/after each test of an interaction. - **au.com.dius.pact.provider.junit.State** custom annotation - before each interaction that requires a state change, all methods annotated by `@State` with appropriate the state listed will be invoked. These methods must either take no parameters or a single Map parameter. ## Example of HTTP test ```java @RunWith(PactRunner.class) // Say JUnit to run tests with custom Runner @Provider("myAwesomeService") // Set up name of tested provider @PactFolder("pacts") // Point where to find pacts (See also section Pacts source in documentation) public class ContractTest { // NOTE: this is just an example of embedded service that listens to requests, you should start here real service @ClassRule //Rule will be applied once: before/after whole contract test suite public static final ClientDriverRule embeddedService = new ClientDriverRule(8332); @BeforeClass //Method will be run once: before whole contract test suite public static void setUpService() { //Run DB, create schema //Run service //... } @Before //Method will be run before each test of interaction public void before() { // Rest data // Mock dependent service responses // ... embeddedService.addExpectation( onRequestTo("/data"), giveEmptyResponse() ); } @State("default", "no-data") // Method will be run before testing interactions that require "default" or "no-data" state public void toDefaultState() { // Prepare service before interaction that require "default" state // ... System.out.println("Now service in default state"); } @State("with-data") // Method will be run before testing interactions that require "with-data" state public void toStateWithData(Map data) { // Prepare service before interaction that require "with-data" state. The provider state data will be passed // in the data parameter // ... System.out.println("Now service in state using data " + data); } @TestTarget // Annotation denotes Target that will be used for tests public final Target target = new HttpTarget(8332); // Out-of-the-box implementation of Target (for more information take a look at Test Target section) } ``` ## Example of AMQP Message test ```java @RunWith(PactRunner.class) // Say JUnit to run tests with custom Runner @Provider("myAwesomeService") // Set up name of tested provider @PactBroker(host="pactbroker", port = "80") public class ConfirmationKafkaContractTest { @TestTarget // Annotation denotes Target that will be used for tests public final Target target = new AmqpTarget(); // Out-of-the-box implementation of Target (for more information take a look at Test Target section) @BeforeClass //Method will be run once: before whole contract test suite public static void setUpService() { //Run DB, create schema //Run service //... } @Before //Method will be run before each test of interaction public void before() { // Message data preparation // ... } @PactVerifyProvider('an order confirmation message') String verifyMessageForOrder() { Order order = new Order() order.setId(10000004) order.setPrice(BigDecimal.TEN) order.setUnits(15) def message = new ConfirmationKafkaMessageBuilder() .withOrder(order) .build() JsonOutput.toJson(message) } } ``` ## Provider state callback methods For the provider states in the pact being verified, you can define methods to be invoked to setup the correct state for each interaction. Just annotate a method with the `au.com.dius.pact.provider.junit.State` annotation and the method will be invoked before the interaction is verified. For example: ```java @State("SomeProviderState") // Must match the state description in the pact file public void someProviderState() { // Do what you need to set the correct state } ``` If there are parameters in the pact file, just add a Map parameter to the method to be able to access those parameters. ```java @State("SomeProviderState") public void someProviderState(Map<String, Object> providerStateParameters) { // Do what you need to set the correct state } ``` ### Provider state teardown methods [3.5.22+] If you need to tear down your provider state, you can annotate a method with the `@State` annotation with the action set to `StateChangeAction.TEARDOWN` and it will be invoked after the interaction is verified. ```java @State("SomeProviderState", action = StateChangeAction.TEARDOWN) public void someProviderStateCleanup() { // Do what you need to to teardown the state } ``` #### Returning values that can be injected (3.6.11+) You can have values from the provider state callbacks be injected into most places (paths, query parameters, headers, bodies, etc.). This works by using the V3 spec generators with provider state callbacks that return values. One example of where this would be useful is API calls that require an ID which would be auto-generated by the database on the provider side, so there is no way to know what the ID would be beforehand. There are methods on the consumer DSLs that can provider an expression that contains variables (like '/api/user/au.com.dius:pact-jvm-provider-junit_2.12:jar:3.6.15' for the path). The provider state callback can then return a map for values, and the `id` attribute from the map will be expanded in the expression. For this to work, just make your provider state method return a Map of the values. ### Using multiple classes for the state change methods If you have a large number of state change methods, you can split things up by moving them to other classes. There are two ways you can do this: #### Use interfaces You can put the state change methods on interfaces and then have your test class implement those interfaces. See [StateAnnotationsOnInterfaceTest](src/test/java/au/com/dius/pact/provider/junit/StateAnnotationsOnInterfaceTest.java) for an example. #### Specify the additional classes on the test target You can provide the additional classes to the test target with the `withStateHandler` or `setStateHandlers` methods. See [BooksPactProviderTest](pact-jvm-provider-spring/src/test/java/au/com/dius/pact/provider/spring/BooksPactProviderTest.java) for an example. ## Pact source The Pact runner will automatically collect pacts based on annotations on the test class. For this purpose there are 3 out-of-the-box options (files from a directory, files from a set of URLs or a pact broker) or you can easily add your own Pact source. If you need to load a single pact file from the file system, use the `PactUrl` with the URL set to the file path. **Note:** You can only define one source of pacts per test class. ### Download pacts from a pact-broker To use pacts from a Pact Broker, annotate the test class with `@PactBroker(host="host.of.pact.broker.com", port = "80")`. From _version 3.2.2/2.4.3+_ you can also specify the protocol, which defaults to "http". The pact broker will be queried for all pacts with the same name as the provider annotation. For example, test all pacts for the "Activity Service" in the pact broker: ```java @RunWith(PactRunner.class) @Provider("Activity Service") @PactBroker(host = "localhost", port = "80") public class PactJUnitTest { @TestTarget public final Target target = new HttpTarget(5050); } ``` #### _Version 3.2.3/2.4.4+_ - Using Java System properties The pact broker loader was updated to allow system properties to be used for the hostname, port or protocol. The port was changed to a string to allow expressions to be set. To use a system property or environment variable, you can place the property name in `${}` expression de-markers: ```java @PactBroker(host="${pactbroker.hostname}", port = "80") ``` You can provide a default value by separating the property name with a colon (`:`): ```java @PactBroker(host="${pactbroker.hostname:localhost}", port = "80") ``` #### _Version 3.5.3+_ - More Java System properties The default values of the `@PactBroker` annotation now enable variable interpolation. The following keys may be managed through the environment * `pactbroker.host` * `pactbroker.port` * `pactbroker.protocol` * `pactbroker.tags` (comma separated) * `pactbroker.auth.username` (for basic auth) * `pactbroker.auth.password` (for basic auth) * `pactbroker.auth.token` (for bearer auth) * `pactbroker.consumers` (comma separated list to filter pacts by consumer; if not provided, will fetch all pacts for the provider) #### _Version 3.2.4/2.4.6+_ - Using tags with the pact broker The pact broker allows different versions to be tagged. To load all the pacts: ```java @PactBroker(host="pactbroker", port = "80", tags = {"latest", "dev", "prod"}) ``` The default value for tags is `latest` which is not actually a tag but instead corresponds to the latest version ignoring the tags. If there are multiple consumers matching the name specified in the provider annotation then the latest pact for each of the consumers is loaded. For any other value the latest pact tagged with the specified tag is loaded. Specifying multiple tags is an OR operation. For example if you specify `tags = {"dev", "prod"}` then both the latest pact file tagged with `dev` and the latest pact file taggged with `prod` is loaded. #### _Version 3.3.4/2.4.19+_ - Using basic auth with the with the pact broker You can use basic authentication with the `@PactBroker` annotation by setting the `authentication` value to a `@PactBrokerAuth` annotation. For example: ```java @PactBroker(host = "${pactbroker.url:localhost}", port = "1234", tags = {"latest", "prod", "dev"}, authentication = @PactBrokerAuth(username = "test", password = "test")) ``` Bearer tokens are also supported. For example: ```java @PactBroker(host = "${pactbroker.url:localhost}", port = "1234", tags = {"latest", "prod", "dev"}, authentication = @PactBrokerAuth(token = "test")) ``` The `token`, `username` and `password` values also take Java system property expressions. Preemptive Authentication can be enabled by setting the `pact.pactbroker.httpclient.usePreemptiveAuthentication` Java system property to `true`. ### Pact Url To use pacts from urls annotate the test class with ```java @PactUrl(urls = {"http://build.server/zoo_app-animal_service.json"} ) ``` If you need to load a single pact file from the file system, you can use the `PactUrl` with the URL set to the file path. ### Pact folder To use pacts from a resource folder of the project annotate test class with ```java @PactFolder("subfolder/in/resource/directory") ``` ### Custom pacts source It's possible to use a custom Pact source. For this, implement interface `au.com.dius.pact.provider.junit.loader.PactLoader` and annotate the test class with `@PactSource(MyOwnPactLoader.class)`. **Note:** class `MyOwnPactLoader` must have a default empty constructor or a constructor with one argument of class `Class` which at runtime will be the test class so you can get custom annotations of test class. ### Filtering the interactions that are verified [version 3.5.3+] By default, the pact runner will verify all pacts for the given provider. You can filter the pacts and interactions by the following methods. #### Filtering by Consumer You can run only those pacts for a particular consumer by adding a `@Consumer` annotation to the test class. For example: ```java @RunWith(PactRunner.class) @Provider("Activity Service") @Consumer("Activity Consumer") @PactBroker(host = "localhost", port = "80") public class PactJUnitTest { @TestTarget public final Target target = new HttpTarget(5050); } ``` #### Filtering by Provider State You can filter the interactions that are executed by adding a `@PactFilter` annotation to your test class. The pact filter annotation will then only verify interactions that have a matching provider state. You can provide multiple states to match with. For example: ```java @RunWith(PactRunner.class) @Provider("Activity Service") @PactBroker(host = "localhost", port = "80") @PactFilter('Activity 100 exists in the database') public class PactJUnitTest { @TestTarget public final Target target = new HttpTarget(5050); } ``` You can also use regular expressions with the filter [version 3.5.3+]. For example: ```java @RunWith(PactRunner.class) @PactFilter('Activity \\d+ exists in the database') public class PactJUnitTest { } ``` ### Setting the test to not fail when no pacts are found [version 3.5.3+] By default the pact runner will fail the verification test if no pact files are found to verify. To change the failure into a warning, add a `@IgnoreNoPactsToVerify` annotation to your test class. #### Ignoring IO errors loading pact files [version 3.5.24+] You can also set the test to ignore any IO and parser exceptions when loading the pact files by setting the `ignoreIoErrors` attribute on the annotation to `"true"` or setting the JVM system property `pact.verification.ignoreIoErrors` to `true`. ** WARNING! Do not enable this on your CI server, as this could result in your build passing with no providers having been verified due to a configuration error. ** ## Test target The field in test class of type `au.com.dius.pact.provider.junit.target.Target` annotated with `au.com.dius.pact.provider.junit.target.TestTarget` will be used for actual Interaction execution and asserting of contract. **Note:** there must be exactly 1 such field, otherwise an `InitializationException` will be thrown. ### HttpTarget `au.com.dius.pact.provider.junit.target.HttpTarget` - out-of-the-box implementation of `au.com.dius.pact.provider.junit.target.Target` that will play pacts as http request and assert response from service by matching rules from pact. _Version 3.2.2/2.4.3+_ you can also specify the protocol, defaults to "http". ### AmqpTarget `au.com.dius.pact.provider.junit.target.AmqpTarget` - out-of-the-box implementation of `au.com.dius.pact.provider.junit.target.Target` that will play pacts as an AMQP message and assert response from service by matching rules from pact. **Note for Maven users:** If you use Maven to run your tests, you will have to make sure that the Maven Surefire plugin is at least version 2.22.1 uses an isolated classpath. For example, configure it by adding the following to your POM: ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.22.1</version> <configuration> <useSystemClassLoader>false</useSystemClassLoader> </configuration> </plugin> ``` #### Modifying the requests before they are sent [Version 3.2.3/2.4.5+] Sometimes you may need to add things to the requests that can't be persisted in a pact file. Examples of these would be authentication tokens, which have a small life span. The HttpTarget supports request filters by annotating methods on the test class with `@TargetRequestFilter`. These methods must be public void methods that take a single HttpRequest parameter. For example: ```java @TargetRequestFilter public void exampleRequestFilter(HttpRequest request) { request.addHeader("Authorization", "OAUTH hdsagasjhgdjashgdah..."); } ``` __*Important Note:*__ You should only use this feature for things that can not be persisted in the pact file. By modifying the request, you are potentially modifying the contract from the consumer tests! #### Turning off URL decoding of the paths in the pact file [version 3.3.3+] By default the paths loaded from the pact file will be decoded before the request is sent to the provider. To turn this behaviour off, set the system property `pact.verifier.disableUrlPathDecoding` to `true`. __*Important Note:*__ If you turn off the url path decoding, you need to ensure that the paths in the pact files are correctly encoded. The verifier will not be able to make a request with an invalid encoded path. ### Custom Test Target It's possible to use custom `Target`, for that interface `Target` should be implemented and this class can be used instead of `HttpTarget`. # Verification Reports [versions 3.2.7/2.4.9+] The default test behaviour is to display the verification being done to the console, and pass or fail the test via the normal JUnit mechanism. From versions 3.2.7/2.4.9+, additional reports can be generated from the tests. ## Enabling additional reports via annotations on the test classes A `@VerificationReports` annotation can be added to any pact test class which will control the verification output. The annotation takes a list report types and an optional report directory (defaults to "target/pact/reports"). The currently supported report types are `console`, `markdown` and `json`. For example: ```java @VerificationReports({"console", "markdown"}) public class MyPactTest { ``` will enable the markdown report in addition to the normal console output. And, ```java @VerificationReports(value = {"markdown"}, reportDir = "/myreports") public class MyPactTest { ``` will disable the normal console output and write the markdown reports to "/myreports". ## Enabling additional reports via Java system properties or environment variables The additional reports can also be enabled with Java System properties or environment variables. The following two properties have been introduced: `pact.verification.reports` and `pact.verification.reportDir`. `pact.verification.reports` is the comma separated list of report types to enable (e.g. `console,json,markdown`). `pact.verification.reportDir` is the directory to write reports to (defaults to "target/pact/reports"). ## Additional Reports The following report types are available in addition to console output (`console`, which is enabled by default): `markdown`, `json`. You can also provide a fully qualified classname as report so custom reports are also supported. This class must implement `au.com.dius.pact.provider.reporters.VerifierReporter` interface in order to be correct custom implementation of a report. # Publishing verification results to a Pact Broker [version 3.5.4+] For pacts that are loaded from a Pact Broker, the results of running the verification can be published back to the broker against the URL for the pact. You will be able to see the result on the Pact Broker home screen. You need to set the version of the provider that is verified using the `pact.provider.version` system property. To enable publishing of results, set the property `pact.verifier.publishResults` to `true` [version 3.5.18+].
Letzte Version: 3.6.15
Freigabedatum:
Letzte Version: 3.1.2
Freigabedatum:
Letzte Version: 4.1.8
Freigabedatum:
Letzte Version: 3.3.0.0-SNAP2
Freigabedatum:Letzte Version: 1.0.1-release
Freigabedatum:
Dekorate :: Testing :: Kubernetes
io.dekorate : kubernetes-junitA collection of annotations and processors for Kubernetes
Letzte Version: 2.8.0
Freigabedatum:
allure-junit-platform
io.qameta.allure : allure-junit-platformModule allure-junit-platform of Allure Framework.
Letzte Version: 2.17.2
Freigabedatum:
Letzte Version: 2.1.4
Freigabedatum:
qala-datagen-junit5
io.qala.datagen : qala-datagen-junit5Java lib to generate random data to facilitate Randomized Testing.
Letzte Version: 2.5.1
Freigabedatum:Letzte Version: 0.0.1
Freigabedatum:Xenei Contract Tests - JUnit Suite
org.xenei : junit-contractsCode to create test suites that run suites of contract tests based on class hierarchy
Letzte Version: 0.2.0
Freigabedatum:Vert.x JUnit 5 RxJava3 support
io.vertx : vertx-junit5-rx-java3Sonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/
Letzte Version: 4.2.4
Freigabedatum:JGit - JUnit Utility Classes
com.bacoder.jgit : org.eclipse.jgit.junitUtility classes to support JUnit testing of JGit applications.
Letzte Version: 3.1.0-201309071158-r
Freigabedatum:
Letzte Version: 1.0.0-SNAP9
Freigabedatum:
powermock-mockito-single-jar-release-full
org.powermock : powermock-mockito-release-fullSingle jar containing source and binaries for PowerMock core and all modules.
Letzte Version: 1.6.4
Freigabedatum:
Letzte Version: 1.0.0-SNAP5
Freigabedatum:
org-netbeans-libs-testng
org.netbeans.api : org-netbeans-libs-testngApache NetBeans is an integrated development environment, tooling platform, and application framework.
Letzte Version: RELEASE126
Freigabedatum:
Letzte Version: 3.1.2
Freigabedatum:wiselenium testng
com.github.wiselenium : wiselenium-testngwiselenium module for convenience test creation using TestNG.
Letzte Version: 0.3.0
Freigabedatum:
Letzte Version: 2.0.9
Freigabedatum:
Dekorate :: Testing :: Openshift
io.dekorate : openshift-junitA collection of annotations and processors for Kubernetes
Letzte Version: 2.8.0
Freigabedatum:SureFire JUnit Runner
org.apache.maven.surefire : surefire-junitSurefire is a test framework project.
Letzte Version: 2.6
Freigabedatum:
junit-interface
com.geirsson : junit-interfaceAn implementation of sbt's test interface for JUnit 4
Letzte Version: 0.11.11
Freigabedatum:
Letzte Version: 3.0.0-M5
Freigabedatum:junit-interface
com.github.sbt : junit-interfaceAn implementation of sbt's test interface for JUnit 4
Letzte Version: 0.13.3
Freigabedatum:
Dekorate :: Starters :: Kubernetes :: Junit
io.dekorate : kubernetes-junit-starterA collection of annotations and processors for Kubernetes
Letzte Version: 2.8.0
Freigabedatum:
Dekorate :: Starters :: Openshift :: Junit
io.dekorate : openshift-junit-starterA collection of annotations and processors for Kubernetes
Letzte Version: 2.8.0
Freigabedatum:Letzte Version: 1.0.1
Freigabedatum:tljunit surefire RunListeners
net.oneandone.testlinkjunit : tljunit-surefireCurrently two RunListeners, one of which writes an Testlink compatible XML file, the other one logs to an injected slf4j Logger.
Letzte Version: 3.0.2
Freigabedatum:
Zucchini Web JUnit
de.codecentric.zucchini : zucchini-web-junitWeb testing tools integration for JUnit.
Letzte Version: 2.1.0
Freigabedatum:Letzte Version: 0.4
Freigabedatum:
rapidpm-junit5-ext-servlet-container-bom
org.rapidpm : rapidpm-junit5-ext-servlet-container-bomjUnit5 Extension to start/stop Servlet Container for a test
Letzte Version: 01.00.04-RPM
Freigabedatum:junit-customclassloader
com.github.mjeanroy : junit-customclassloaderRun your JUnit 4 tests with a custom classloader.
Letzte Version: 0.1.1
Freigabedatum:Timber-JUnit-Rule
net.lachlanmckee : timber-junit-ruleJUnit TestRule that pipes Android Timber logs to the standard console
Letzte Version: 1.0.1
Freigabedatum:Letzte Version: 0.5
Freigabedatum:
de.rwth.swc.coffee4j:coffee4j-junit-engine
de.rwth.swc.coffee4j : coffee4j-junit-enginecoffee4j is a framework that integrates combinatorial test generation and automated test execution via JUnit5
Letzte Version: 1.0.7
Freigabedatum:
org-netbeans-modules-junit-ui
org.netbeans.modules : org-netbeans-modules-junit-uiApache NetBeans is an integrated development environment, tooling platform, and application framework.
Letzte Version: RELEASE126
Freigabedatum:junit-core
com.fitbur.testify.junit : junit-coreAn opinionated Java Testing Framework faithful to testing principles and best practices.
Letzte Version: 0.1.3
Freigabedatum:
Letzte Version: 2.0.0-alpha-1
Freigabedatum:Letzte Version: 0.2.0
Freigabedatum:
rider-junit5
com.github.database-rider : rider-junit5Database testing made easy with JUnit and DBUnit.
Letzte Version: 1.32.1
Freigabedatum:Letzte Version: 0.2.4
Freigabedatum:Letzte Version: 0.7.13b
Freigabedatum:Letzte Version: 1.2.1
Freigabedatum:Quarkus - Test Framework - JUnit 5 - Properties
io.quarkus : quarkus-junit5-propertiesContains junit-platform.properties in a "use-excludable" way until https://github.com/junit-team/junit5/issues/2794 is available.
Letzte Version: 2.7.0.CR1
Freigabedatum:
Avito Android Infrastructure
com.avito.android : junit-utilsCollection of infrastructure libraries and gradle plugins of Avito Android project
Letzte Version: 2021.41
Freigabedatum:quick-perf-junit4
org.quickperf : quick-perf-junit4QuickPerf is a testing library for Java providing annotations to quickly evaluate some performance properties.
Letzte Version: 1.1.0
Freigabedatum:
Letzte Version: 3.0.0-M5
Freigabedatum:JUnit Runner
com.github.junitrunner : junitrunnerThe extension friendly JUnit Runner with support for plugins
Letzte Version: 0.0.2
Freigabedatum:SmallRye Mutiny - Vert.x JUnit 5 support
io.smallrye.reactive : smallrye-mutiny-vertx-junit5SmallRye Build Parent POM
Letzte Version: 2.18.1
Freigabedatum:
FluentXML4J JUnit Extensions
com.github.fluentxml4j : fluentxml4j-junitCollection of junit extensions for tests with xml.
Letzte Version: 2.2.1
Freigabedatum:
Letzte Version: 1.0.0-SNAP5
Freigabedatum:sticky-mockwire-mockito
net.stickycode.mockwire : sticky-mockwire-mockitoMockito mocker implementation for Mockwire, used to provide mocks of services not under test in an isolated context
Letzte Version: 8.1
Freigabedatum:
Letzte Version: 1.0.0-SNAP5
Freigabedatum:Mockito-Java8
info.solidsoft.mockito : mockito-java8Mockito add-ons leveraging Java 8 and lambda expressions to make mocking even more compact
Letzte Version: 2.5.0
Freigabedatum:
Letzte Version: 1.5.0
Freigabedatum:
Letzte Version: 4.0.0
Freigabedatum:
Letzte Version: 1.5.8
Freigabedatum:mockito-extension
eu.benschroeder : mockito-extensionExtension for writing unit tests with mockito and avoid static imports
Letzte Version: 4.1.0
Freigabedatum:Letzte Version: 4.4.7
Freigabedatum:Letzte Version: 2.0
Freigabedatum:
org-netbeans-modules-testng
org.netbeans.modules : org-netbeans-modules-testngApache NetBeans is an integrated development environment, tooling platform, and application framework.
Letzte Version: RELEASE126
Freigabedatum:FEST Swing - JUnit Extension
org.easytesting : fest-swing-junitJUnit-specific extension for FEST-Swing
Letzte Version: 1.2.1
Freigabedatum:
Letzte Version: 3.1.2
Freigabedatum:
Letzte Version: 2.0.0-RC1
Freigabedatum:rxmicro-test-junit
io.rxmicro : rxmicro-test-junitThe module designed for test writing using the JUnit 5 framework.
Letzte Version: 0.9
Freigabedatum:JBehave junit support
org.jbehavesupport : jbehave-junit-supportSupport for running jbehave stories as junit test cases.
Letzte Version: 4.8.3.1
Freigabedatum:
Letzte Version: 5.0.0-ALPHA
Freigabedatum:Letzte Version: 1.1.9
Freigabedatum:junit5-kubernetes
com.github.jeanbaptistewatenberg.junit5kubernetes : coreUse pod and other kubernetes object right form your junit5 tests.
Letzte Version: 2.3.1-beta
Freigabedatum:
JEAF JUnit Extensions Impl
com.anaptecs.jeaf.junit : jeaf-junit-extensionsProject provides a JUnit extensions so that JEAF Services can be run in JUnit environments without having the need to start a web or application server.
Letzte Version: 1.6.5
Freigabedatum:
kafka-junit-core
com.salesforce.kafka.test : kafka-junit-coreThis library wraps Kafka's embedded test cluster, allowing you to more easily create and run integration tests using JUnit against a "real" kafka server running within the context of your tests.
Letzte Version: 3.2.3
Freigabedatum:Quarkus - Test framework - JUnit 5 - Vert.x
io.quarkus : quarkus-junit5-vertxBuild parent to bring in required dependencies
Letzte Version: 2.7.0.CR1
Freigabedatum:Letzte Version: 1.8.0
Freigabedatum:Letzte Version: 0.2.3
Freigabedatum: