Automatic integration tests as part of the development life cycle can save a lot of time and money. Not only when dealing with other service APIs or offering some, also if the application uses a database or other infrastructure services.
We at Consol made a lot of good experience to develop the integration tests as part of the life cycle from the beginning of a project. Therefor the Citrus framework is often a good choice to do it automated.
But there are other frameworks and libraries which can be useful. In this article, we’ll have a look at Testcontainers. By using a sample microservice, we will show how Testcontainers can be used and what chances it provides.
Database communication is an essential part of many applications, when persistent data storage is required. May it be orders, customer data, product recommendations or product information, if persistent storage is in place, the data contains a certain business value. Therefore it’s important that your software handles your persistent storage the right way.
In this blog post you’ll learn how to test your database communication using Citrus.
When developing software that exchanges data with other components or services you may be confronted with the proper simulation of those foreign services during integration testing. This is because you need to connect with a foreign service
that is simply not available on your local machine or in a test environment.
For unit testing purpose you can use mocks that help out to simulate proper responses. There will be times where your software is deployed to a test environment
in order to perform some acceptance tests with your stakeholders before going to a final release. Usually this is also done with the customer exploring the software through manual testing. In these situations traditional service mocking is not
a good option and you need a real simulator instance that receives requests and responds with proper test data.
This is exactly what the Citrus simulator project provides for you. Standalone simulation and complex request/response processing with solid validation capabilities. The Citrus simulator provides a very easy and reliable definition of inbound and outbound messages for different scenarios.
Good news is that this is not only for Http REST interfaces but also for SOAP WebService, JMS, RMI, mail messaging and many more. So you can use the simulator whenever you need to integrate with another service that is simply not available on your local machine or in your test environment.
The GitHub repository toschneck/openshift-example-bakery-ci-pipeline contains, the sourcecode for the examples of the talk Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-Pipelines at the Redhat/ConSol OpenShift-Day:
It has been a while since the last release in the Citrus universe. It took us some time to get the new Citrus release 2.7.2 ready for you.
Of course we were not being lazy in that time. Besides the new Citrus 2.7.2 release we are proud to announce a new player in the Citrus team. The Citrus administration UI is a
web-based user interface that helps you to manage your Citrus projects and test cases.
Often users complained about the complexity of having to learn all about Citrus and the Spring framework in particular as Citrus uses Spring for configuration and dependency injection.
Especially non-developers had problems to master the learning curve for Citrus and Spring when starting to use the framework. Also people asked for a way to have a user interface for managing
components and tests.
We heard you and introduced a new administration user interface for Citrus! There is a detailed Citrus Admin documentation (which is still ongoing).
However I would like to outline the main features of that web UI here in a short post for you.
DevoxxUS has been my first Devoxx outside of Europe so far. It was a total different Devoxx experience for me compared to the six times in Antwerp Belgium that I have been to in the past years.
Yet different it has been a great conference! I would like to share some of my adventures and thoughts in this post.
The ELK-Stack is a good option to aggregate and visualize distributed logging-data. It basically based on
The core of the most ELK applications is the Logstash configuration. A user defines here which data (inputs) is processed, how (filter) the data is processed and where it will go afterwards (outputs). Especilly this configuration contains a lot of logic which is unfortunally not easy to test. In this article I want to show you how to setup a testing environment for your Logstash configuration.
In about three weeks [DevoxxUS] will take place in San Jose, California on March 21-23. After having visited Devoxx Belgium six
consecutive times this will be my first Devoxx conference outside of Europe. Once again I am honored
to be a speaker at that conference! After my Devoxx BE talk in 2015 ([Testing Microservices with a Citrus twist]) this is my second time speaking
in front of Devoxxians from all around the world. Fantastic!
This time I am going to talk about behavior driven integration with [Cucumber] and [Citrus].
Die Software-Entwicklung ist im Wandel. Immer schneller, immer häufiger, immer einfacher müssen neue Features in Produktion gebracht werden. Große, schwergewichtige Alleskönner werden durch mehrere kleine, individuelle Services ersetzt. Jeder Microservice bildet einen Aspekt der gesamten Fachlichkeit ab und lässt sich deshalb unabhängig entwickeln und warten. …
Der vollständige Artikel ist in der Java aktuell 01-2017 zu finden:
In a previous article we went through how to build a chat room web application that used REST and STOMP for communicating between the client and server. In this article I use the very same application and show how to write automated integration tests using the open source Citrus integration test framework.
If you haven’t read the first article don’t worry. A quick summary of all the important bits will be shown shortly below. But before I get to that lets talk a little bit about automated integration testing and citrus.
One of the biggest challenges when testing any application is being able to simulate all endpoints.
Fabian and Christoph have been invited to speak at [Devoxx Conference] 2016 in Antwerp, Belgium. Watch their talks to learn more about HTTP2 and Citrus Framework.
Some time has passed since part one of this blog post series and we have made some improvements on the Citrus Arquillian extension.
So we can look forward to this post as we move on with a more complex test scenario where we include some Citrus mail server within our test. In part one we have already combined both frameworks Arquillian
and Citrus with a basic example.
Citrus and Arquillian
both refer to themselves as integration test frameworks. Following from that you might think these frameworks somehow ship the same package but this is not the case. In fact the frameworks work
brilliant together when it comes to automate the integration testing of JEE applications.
In this post I will continue with the Apache Camel integration testing scenario that we have worked on in part one and part two of this series.
This time we focus on exception handling in Camel routes. First of all let’s add exception handling to our Camel route.
In part one of this blog series we have used Citrus in combination with Apache Camel for setting up a complete integration test scenario. Remember we have interacted with our Camel route
via JMS as client and via SOAP Http WebService as a server.
Now in the second part we want to interact with a Camel route using direct and Seda in memory message transports. First of all we need a Camel route to test.
Apache Camel is a great mediation and routing framework that integrates with almost every enterprise messaging transport. In the past I have experienced Camel projects struggling with integration testing where the actual message interfaces to boundary applications are not tested properly in an automated way.
So in a series of posts I would like to talk about integration testing strategies for Apache Camel projects using the Citrus integration test framework.
In Part I of this tutorial I introduced the basic concepts and benefits of Citrus as a test driver for ESB projects in general and webMethods in particular. In this second part I want to discuss some Citrus project setup options and provide a quickstart template project for Ant users.
A new package of the Open Source integration test framework Citrus has just arrived. Version 1.4 comes with new features such as data dictionaries, SMTP mail support and an improved endpoints API for easier configuration. See the 1.4 documentation changes report for a detailed overview on all changes.
With the new configuration components we give credit to all users continuously giving us feedback on the Citrus configuration. With 1.4 our primary goal was to simplify the configuration without loosing the great extendability and customization capabilities of Citrus.
If you are coming from Citrus 1.x we have summarized the configuration changes in this migration sheet.
The old Citrus configuration components were marked as deprecated, so you can continue to use those components when upgrading to 1.4 without any changes. However you should consider to upgrade to the new endpoint configuration in order to be ready for the upcoming versions.
Also have a look at the new config sheet to see how the new configuration works for you.
Continuous integration is almost mainstream nowadays. Probably no one wants to argue against the value of having an all-embracing integration test suite in place, which is lightweight enough to be executed on each code change. In this blog series I want to show the interplay between Citrus, the integration test framework written and maintained by ConSol and a commonly used Enterprise Service Bus, the webMethods Integration Server.
I am excited to announce that Citrus 1.3 has been released! We hope you enjoy the new feature set coming with this version like the new Java test builder for writing tests with Java code only and the new citrus-ssh module that adds connectivity to the ssh protocol as a client or server. Now let’s have a quick look at the major changes with this release.
It has been a while since our last final release for Citrus. Now I am proud to announce the final 1.2 release. The package ships with a huge list of new features and improvements that I would like to highlight in a few lines for you.
Lately I had to deal with Excel files as REST Http service response. I came up with a pretty clever validation mechanism in Citrus that I would like to share with you. You can apply the Excel validator to your Citrus project, too. It is not very complicated as you will see in this post.
TestNG provides brilliant support for test parameters and data providers. With some annotation magic you are able to pass parameter values to your test method and finally to your Citrus test logic.
The next Citrus milestone release for version 1.2 has landed. This version introduces new REST Http support on client and server side. In particular we are now able to handle the Http request methods (GET, POST, PUT, DELETE, …) as well as Http response codes (e.g. 404 Not Found).
Citrus 1.2.M2 now works with Spring 3.0, Spring Integration 2.0 and Spring WS 2.0. In addition to that we have some bugfixes and improvements in this release. Check out the reference documentation for the complete changes list on what’s new.
We are very happy to announce the first milestone release of Citrus 1.2 in early 2011. The framework comes with great new features and many improvements to you. This post gives a short overview of the major changes, hope you enjoy the new features:
Citrus includes a lot of convenient features which are only waiting for you to discover and use them. The other day I needed to validate a SoapAttachment. As you probably already know, a SoapAttachment is referenced by a href property in an Include tag like this:
<Include href="..." xmlns="http://www.w3.org/2004/08/xop/include"/>. Validation is quite easy when you’re still mock testing your application because you have full control over what your mock response will look like.
TestNG groups add great flexibility to the Citrus test execution. We are able to divide all tests into several groups reaching a sophisticated seperation of concerns in our test setup. As an example I want to classify some of my functional Citrus tests as “long-running”. These tests may not apply to continuous execution every time I package my project. Instead of this I want to set up a scheduled integration build to execute those long-running tests in a time schedule.
Citrus 1.1 release is here (download)! The release comes with a bunch of new features and bugfixes. Here is a short list of major features and changes in this release:
By setting the SOAP mustUnderstand header attribute to “1”, you indicate that the service provider must process the SOAP header entry. In case the service provider is not able to handle this special header a SOAP fault server error is sent back to the calling client. In this post I would like to point out an easy way to support these mustUnderstand headers when simulating SOAP WebServices with Citrus.
In my last post (citrus-xpath-validation-power) I solved a validation problem regarding generic XML data structures with some XPath expression power. Now in latest 1.1-SNAPSHOT version of Citrus things become even more straightforward.
I recently struggled with the validation of a very generic XML data structure in some message payload. It turned out to be a good example where XPath validation can overcome the normal XML tree comparison. I’d like to share my thoughts about this issue, because others might run into similar problems too and the solution with XPath really impressed me with its powerful validation possibilities.
The Citrus project sources are now available on GitHub for public checkout. You can clone/fork the Citrus project via Git and build your own version on your local machine. Visit the Citrus project site on GitHub for more details.
In larger projects usually a team of testers is working on Citrus integration tests. This means that we need to localize the citrus.properties for testing on different machines, as each tester executes test cases with individual environment settings. In this post I’d like to share an easy way to localize the Citrus settings with Maven.
Test cases in Citrus are usually provided with some meta information like the author’s name or the date of creation. This post shows how to extend on this to include your very specific meta data on your own.
Once you have written Citrus integration tests it would be nice to also use these test scenarios for performance testing. In a recent project we accomplished basic performance tests just using some out-of-the-box features in TestNG. In this post I would like to share a simple example with you regarding performance testing in Citrus.
We fixed some issues in our 1.1-SNAPSHOT version of Citrus and also improved some features. For a detailed change history follow our changes report.
The latest version now supports multi-threaded performance tests. We recently tested a SOAP WebService regarding performance using Citrus. I will try to add a new post describing how to accomplish performance testing with Citrus as soon as possible.
Download the latest snapshot version of Citrus: Download
Citrus is now also available as snapshot release in version 1.1. We already have incorporated some really great new features and fixed some issues. See below a list of new features for 1.1-SNAPSHOT.
New features in first 1.1-SNAPSHOT release:
Testing the latest snapshot version including feedback is now very important for us. Therefore we hope you can switch to the latest snapshot versions. There are still more features to come in version 1.1 so stay tuned. For instance by following Citrus on Twitter (http://twitter.com/citrusframework) where all announcements will reach you right on time.