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.
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
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.
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.
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.
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.
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.
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.
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.
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:
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 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.
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:
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.
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.
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.
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.
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.
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.
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.
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 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.
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.