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.