Skip to main content

Integration Testing A Java Enterprise Application Data Access Layer

Finding the best design approach is only part of the solution to writing an Enterprise Application. As with all software, the application must be tested. Unit tests are the first line of defence, but they only the units of the application individually. You also need to test how the units interact with each other and other parts of the application, such as the database. These sorts of tests are called integration tests.

Soon after I discovered unit testing I accidental discovered integration testing. I was writing a system that interacted with a database at just about every stage. So each of my tests would start by creating and populating the database. Then the tests would be run and afterwards the database would be torn down. Creating and destroying the database for each test ensured that it was always in a known state. It also meant that every test took a very long time to run. When I only had a handful of tests this was not too much of a problem. Once I had in-excess of a hundred tests it was a big problem! A general rule is that tests should take close to zero time to run, or people stop running them.

I started to think about how I could improve the performance of my integration tests. So I created a data access layer as is described in my article Data Access Layer Design for Java Enterprise Applications. This enabled my integration tests, which were only masquerading as unit tests, to become real unit tests as they could use a mocked-out data access layer, rather than a real database, there by reducing their run time to almost zero. However, I still needed to write true integration tests to test the data access layer itself. These tests still needed a real database.

Most of the time taken up in setting up and tearing down a database is in its creation and deletion. The actual insertion, update, reading and deletion of data is relativity quick. Most databases support transactions. Transactions prevent a unit of work from being committed to the database until it is completed successfully. If an error occurs part way through the unit of work the transaction can be rolled back and none of the work carried out is committed. If the unit of work is successful it is committed to the database in its entirety once complete.

This can also be applied to testing. At the beginning of an integration test a transaction is started. As necessary, data is inserted into the database and the tests run, which themselves may insert or remove data. Once the test is complete the transaction is rolled back and the database is returned to its original state before the tests. Even if the test fails, the transaction is rolled back and the database returned to its original state.

Once I discovered this I moved the creation of the database structure (the database itself, tables, views, stored procedures, reference data, etc) to my build script and started running my tests in transactions. This greatly improved the performance of my integration tests.

Read more...

Comments

Popular posts from this blog

Write Your Own Load Balancer: A worked Example

I was out walking with a techie friend of mine I’d not seen for a while and he asked me if I’d written anything recently. I hadn’t, other than an article on data sharing a few months before and I realised I was missing it. Well, not the writing itself, but the end result. In the last few weeks, another friend of mine, John Cricket , has been setting weekly code challenges via linkedin and his new website, https://codingchallenges.fyi/ . They were all quite interesting, but one in particular on writing load balancers appealed, so I thought I’d kill two birds with one stone and write up a worked example. You’ll find my worked example below. The challenge itself is italics and voice is that of John Crickets. The Coding Challenge https://codingchallenges.fyi/challenges/challenge-load-balancer/ Write Your Own Load Balancer This challenge is to build your own application layer load balancer. A load balancer sits in front of a group of servers and routes client requests across all of the serv

Bloodstock 2009

This year was one of the best Bloodstock s ever, which surprised me as the line up didn't look too strong. I haven't come away with a list of bands I want to buy all the albums of, but I did enjoy a lot of the performances. Insomnium[6] sound a lot like Swallow the Sun and Paradise Lost. They put on a very good show. I find a lot of old thrash bands quite boring, but Sodom[5] were quite good. They could have done with a second guitarist and the bass broke in the first song and it seemed to take ages to get it fixed. Saxon[8] gave us some some classic traditional heavy metal. Solid, as expected. The best bit was, following the guitarist standing on a monitor, Biff Bifford ripped off the sign saying "DO NOT STAND" and showed it to the audience. Once their sound was sorted, Arch Enemy[10] stole the show. They turned out not only to be the best band of the day, but of the festival, but then that's what you'd expect from Arch Enemy. Carcass[4] were very disappoin

Catalina-Ant for Tomcat 7

I recently upgraded from Tomcat 6 to Tomcat 7 and all of my Ant deployment scripts stopped working. I eventually worked out why and made the necessary changes, but there doesn’t seem to be a complete description of how to use Catalina-Ant for Tomcat 7 on the web so I thought I'd write one. To start with, make sure Tomcat manager is configured for use by Catalina-Ant. Make sure that manager-script is included in the roles for one of the users in TOMCAT_HOME/conf/tomcat-users.xml . For example: <tomcat-users> <user name="admin" password="s3cr£t" roles="manager-gui, manager-script "/> </tomcat-users> Catalina-Ant for Tomcat 6 was encapsulated within a single JAR file. Catalina-Ant for Tomcat 7 requires four JAR files. One from TOMCAT_HOME/bin : tomcat-juli.jar and three from TOMCAT_HOME/lib: catalina-ant.jar tomcat-coyote.jar tomcat-util.jar There are at least three ways of making the JARs available to Ant: Copy the JARs into th