Integration Testing describes every test, which integrates more than one component that is tested.

Lots of developers are writing test using JUnit, PHPUnit, NUnit and so on. These tests invoke some piece of code, that do something. This „something“ can be a in-memory calculation, access to databases or even accessing remote services. Unit tests are tests which test a single unit, a method, a class. As soon as this method or class tries to access something, which is outside of your working memory, it's most likely an integration test. Integration tests are very valuable, but in most cases you perform integration testing without knowing it. In most cases you'll notice it, as soon as you run your tests without network or somebody kills the database. And then you might be screwed. This example gives some impression what the difficulties are: External systems, services you can't contol (yet), shared databases. Because of these and sometimes because the benefit is not seen integration tests are not automated.

As soon as you start Continuous Delivery you don't want to build artifacts for a specific environment. Once you've built and packaged, you want to reuse it in Dev, UAT, Production and so on.

Do you know Puppet? Puppet is a system management/provisioning tooling. It's intended to specify a set of resources (files, software packages and many more) to be in a certain state. This is very hand for all the cases, where you need for example Apache and PHP, you want to apply an own php.ini, have a customized logrotate.conf, some cron jobs... All this can be specified using Puppet. The first time your system boots, all the specifications are applied and you don't have to copy config files anymore. Puppet runs also every 30mins (by default) to check for new/changed rules.

I’d guess, nearly every developer, who assisted on releasing and go-live of his software ran into the same issue: How to deal with sensitive configuration data such as passwords, keys and tokens? Hard-coding of passwords it out since the late '90s. Writing passwords in plain-text into config-files is as well a security breach. Encrypted passwords within config files are much better but demand you to implement some kind of encryption. Still you have then the problem: Where to put the encryption key?

Some time ago I got in touch with one of my 2006 written applications. I got flashed at the moment I looked into my code.

My intention was to perform some improvements. 2006 had very few frameworks to deal with HTTP interfaces. The most common interface types were GUIs (JSP/JSF) and some SOAP Services. Writing HTTP interfaces for API use (calls from JavaScripts and so on) was still a hard way in Java applications. In most cases servlets were used. Those servlets received either Query- or Form-Params to perform the processing. Sometimes they even accepted/produced some XML. Let me show you some examples and how to solve them using current technology.

Once someone has written a software and he wants to sell it, ideas of licenses and copy protection arise. There are several ways, how software can deal with that: No license control at all, license keys, serial numbers, online activations, encrypted source code. Every type has its pros and cons.

Prior to this article I wrote about testing SOAP WebServices locally. This was accomplished using JAX-WS. Lots of projects still use Axis or Axis2. Therefore I created a simple Axis2 setup to demonstrate JUnit-Testing of WebServices.

It’s a common problem almost which every application has: Where do I put my configuration? Lucky you, rich clients and standalone applications. For most rich client/standalone apps it’s somehow easy, because you have to have somewhere a starter, so you can deploy the config somewhere along the starter. 

In Continuous Delivery you deliver often and to different environments. When it comes to configuration files you have to maintain multiple instances at a time. You can’t just have one fits it all. The Configuration Server is built to support you in this scenario. Basic idea of the Configuration Server is: Serve configuration based on your host for multiple artifacts and versions.

In my last post about Integrationtest-driven development/Test-driven integration I was talking how to get started with integration testing. Sometimes it comes to the point, where your integration tests need more than only a database and a running system: You have additional dependencies like EJB's or Web-Services. What now? You can't always rely on test-systems: Sometimes there aren't any or only shared instances exist. Sometimes it's even harder to simulate a specific scenario using real services because of data and logic dependencies.