Since we wrote this post we didn't laze around. Check our latest announcement.
The Arquillian team is proud to announce the 1.0.0.Alpha3 release of the Arquillian Algeron Extension component!
Important note: This extension was called Arquillian Pact before version 1.0.0.Alpha5, so you should use this name when pulling dependencies from Maven Central.
Arquillian Pact is an extension for writing contract-driven tests which provides integration with Pact framework.
What’s new
Skipping the deployment
In case of consumer driven contracts, there are two kinds of tests – consumer tests and provider tests. Usually in your CI environment you want to run provider tests against two different scenarios:
Against a master branch of provider to detect if provider team has already implemented all the functionalities defined in your contracts.
Against (pre)production. If you support deploying consumer independently of a provider, then you need to ensure that if you deploy new consumer with the new contracts to (pre)production everything will be still working and you haven’t introduced any regressions.
In both cases, the test itself is exactly the same. There is only one slight difference in both cases which how you set up your test environments. In the first scenario, you want to deploy the latest provider code. One way of doing it is using Arquillian container control and @Deployment method to create the package, start the container and deploy it. But in the latter case, when you want to run contract test against provider that is already deployed on (pre)production environment, you don’t need to deploy anything nor control the lifecycle of any container. For this reason we provided skipDeployment flag.
skipDeployment default value by default is set to false, which means that the test will behave as it usually does, but when it is set to true, Arquillian is going to ignore anything related to container lifecycle. To use this strategy your test needs to be defined as `@RunAsClient`. You can think of it as a dynamic way of converting an Arquillian container test into Arquillian standalone test.
Let’s see an example:
@RunWith(Arquillian.class)
@Provider("test_provider")
@PactFolder("pacts")
@RunAsClient
public class MyServiceProviderTest {
@Deployment(testable = false)
public static WebArchive createDeployment() {
return ShrinkWrap.create(WebArchive.class).addClass(MyService.class);
}
@ArquillianResource
@Environment("myservice.url")
URL webapp;
@ArquillianResource
Target target;
@Test
public void should_provide_valid_answers() {
target.testInteraction(webapp);
}
}
Given previous test, if skipDeployment is false, this test will behave like:
- Start chosen application server (Wildfly, TomEE, Tomcat, …)
- Package and Deploy MyService
- Enrich webapp URL with the one provided by application server.
@Environment reference is ignored.
- Executes contract test against deployed application.
- Undeploy and stop everything.
But if you set skipDeployment to true, lifecycle is slightly different:
- Enrich webapp URL with Java system property or environment variable named
myservice.url set in @Environment.
# Executes contract tests against URL provided by @Environment.
There is no additional “behind the scenes” Arquillian magic involved. Notice that with a simple attribute you can enable/disable how Arquillian behaves regarding the deployment lifecycle, and how you can reuse same test (DRY) for different scenarios.
You can read more about this feature in Pact documentation
Provider states with parameters introduced in Version 3 of Pact Spec
You can also use parameters for defining pact states. This feature is introduced in version 3 of pact contract files.
In consumer part you can add states with parameters doing:
Map<String, Object> stateParams = new HashMap<>();
stateParams.put("name", "Alexandra");
return builder
.given("test state", stateParams)
.uponReceiving("ConsumerTest test interaction")
.path("/")
.method("GET")
.willRespondWith()
.status(200)
.headers(header)
.body("{\"responsetest\": true, \"name\": \"harry\"}")
.toFragment();
Notice that you are using given passing state name and parameters.
Then in provider side:
@State("test state")
public void testStateMethod(Map<String, Object> params) {
assertThat(params).containsEntry("name", "Alexandra");
}
Pact Publisher mechanism
Arquillian Pact also offers additional ways to of publishing “pact” contract files comparing to what Pact itself is providing. With Pact you usually need to relay on the build tool to publish “pact” files. Pact offers a Maven and Gradle plugin for publishing contracts to Pact Broker, but if you want to use Git repository or sharing contracts through an arbitrary folder, then you’ll need to start hacking the build tool which is not always as easy as it should be :)
In Arquillian Pact we have defined a Pact Publishing SPI so you can implement your own publisher. We currently support three different publishers – Folder, URL[POST method] and Git.
For example to use it with Folder Publisher, arquillian.xml might look like:
<?xml version="1.0"?>
<arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://jboss.org/schema/arquillian"
xsi:schemaLocation="http://jboss.org/schema/arquillian
http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<extension qualifier="pact-consumer">
<property name="pactPublishConfiguration">
provider: folder
outputFolder: /mypacts
</property>
</extension>
</arquillian>
With this configuration and setting publishContracts to true, Arquillian Pact copies generated contracts to outputFolder.
It is important to note that by default publishContracts configuration attribute is false. This means that when you run any consumer contract test, contracts are not published. publishContracts configuration attribute should be only set to true if and only if you are publishing a new version of a consumer, and this will be done by your CI/CD environment.
You can set outputFolder value using Java system property.
You can read more about this feature in Pact documentation
Bug fixing
GitPactLoader – password field as passphrase bug
GitPactLoader was using password field as passphrase which is totally wrong since passphrase of a private key is not a password. issue-31
GitPactLoader – always using default key
GitPactLoader was always using default key instead of the one in current user home directory.
What is Arquillian?
Arquillian is open source software that empowers you to test JVM-based applications more effectively. Created to defend the software galaxy from bugs, Arquillian brings your test to the runtime so you can focus on testing your application's behavior rather than managing the runtime. Using Arquillian, you can develop a comprehensive suite of tests from the convenience of your IDE and run them in any IDE, build tool or continuous integration environment.
Release details
Published artifacts
org.arquillian.pact
-
org.arquillian.pact
»
arquillian-pact-consumer-api
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-consumer-core
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-consumer-spi
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-consumer-git-publisher
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-provider-api
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-provider-core
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-provider-spi
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-provider-pact-broker-loader
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-provider-maven-loader
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-provider-git-loader
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-git
jar
javadoc
pom
-
org.arquillian.pact
»
arquillian-pact-configuration
jar
javadoc
pom
Release notes and resolved issues
8
- Enhancement
-
- Bug
-
Thanks to the following list of contributors:
Bartosz Majsak, Alex Soto, Eddú Meléndez Gonzales
