Have we not all dreamt of the ultimate integration testing?

Have you ever achieved it in your company? I have worked in a couple companies and yet have to see it done the ultimate way.

Mostly it boils down to a combination of one, if not all, of these problems

  • not enough resources (invalid manager or lazy peon argument)
  • to many stakeholders and all use the same environment(s)
  • data is constantly changing, data is polluted
  • silo’s
  • unstable releases of dependencies wrecking tests
  • no automation what soever
  • no integration testing whatsoever (no kidding, it happens)
  • no build server ( huh what? you still build on your local machine??)
  • a backward ops team reluctant to do cool stuff

you can probably find some more reasons! feel free to let me know.

So let’s create a situation. Let’s say you have a simple infrastructure:

  • database servers
  • micro services ( API’s)
  • front end applications

All of them being built by different teams.

  • Team DB does databases,
  • Team MS builds the java backend services
  • Team FE does some nodejs fronted magic

Let’s also assume you have at least 3 different environments: development, test and production. Each of them a version of all applications on it.

Suppose that you have at least the problem of data consistency and unstable test wrecking dependencies. Then your current scenario could be something like:

  1. Team DB updates a database schema Z to version 2, tries it out on development. “Yay it’s works! Our update scripts are mighty cool! Let’s rollout to test.
  2. Team MS, sitting close by, quickly noticing the failing build on the CI Server. “Ho Ho Ho! Wait let us update our service Y that uses your update DB X.“. Update done, deploy to development. Runs some tests to verify that implementations correctly use the new database with it’s new functionalities . “Yay it works! Rollout to test!” Run the integration suite all seems fine!
  3. BOOM, front end was just giving a demo to stake holders on the test environment. An angry product owner with on it’s tail 15 nodejs developer storms in the back end room shouting all over the open space. “WTF #$FJIEAÏOXCBVEEEE$HIT# what where you thinking releasing that to test! We search a street name in your service and we get only cities back!  And the search name we initially use in our demo isn’t there anymore!!  You broke our whole front end! Fubar our demo! AGAIN !”
    Frustration, depression, the downfall of the team spirits, the downfall of a company, IMPEDIMENTS.

Well now! WE ARE ALL SAVED from this!  Just call 1-800-DOCKERIZEwarning next up is simple theoretical docker porn 
Continue reading “Have we not all dreamt of the ultimate integration testing?”

Unit testing the database layer

Testing the database layer. Usually an important part of many applications and thus everyone should test it.

But how do you do that?
(if you know how it’s done, this post is not for you, go read something more interesting then!)

You don’t want to setup an Oracle, MySQL, PostgreSQL and such just for running unit tests. Your option? Use an in memory database!

There are a couple of tools available on the opensource market to test your dao layer. I’ve put together an example for a database layer that is using Spring 3.1.2 with JPA2/Hibernate 4.x. For testing I choose the combination of Unitils, H2 in memory database and JUnit.

Unitils is the thing that creates the database using your entities or if you want it can also create your database using an sql script. I usually let hibernate create the database. And add some <dataset> xmls with data.

You can find the example code at github.

Take a look at the tests in src/test/java to see how it is done. There is one test that uses an xml file to populate the database and another test without an xml file. I’ve added Javadoc to the tests to explain what is happening.

This way of testing also allows you to test your service layer with a predefined dataset. Personally I prefer to mock stuff in the service layers. But for doing integration tests it can be useful to have an in memory database.

Happy Testing!

Stop copying that TestSuccessException

Finally you can stop copying that TestSuccessException you write when writing tests with mocking.

I’ve put it in a jar and uploaded it to Maven Central.


The code is on GitHub there is also an EmptyHttpServletRequest, can be useful when calling methods that need a HttpServletRequest as parameter. ( e.g. in Mockito you can’t mock interfaces, so you can mock with the EmptyHttpServletRequest )

At the time being those where the one I needed, want to add more? Just leave an issue on GitHub and/or send a pull request for interesting stuff.

%d bloggers like this: