Integration Testing is an important type of test to have in place. It’s purpose is to verify the integration of your specific components with for example; a Database, a Framework, a 3rd party external system etc.
In this blog post i am going to show you how easy it is to do Integration Testing for testing the integration with a Database.
Assuming you are working with a relational database here. Integration Testing with a NoSQL datastore merits a completely different article on itself as it is a big topic in itself too. I’m not going to cover that in this post.
Also assuming you are using a Layered Architecture — which most software systems are built using this architectural pattern these days. You would have either a DAO (Data Access Object) and/or a Repository. Either of these, their purpose is to act as a facade for your business logic in communicating with the database. They sit in the Data Access Layer (DAL).
For this example, i am going to use the more traditional (and perhaps a bit old-fashioned) pattern of the DAO.
So let’s say you have a DAO in place and that it contains the following bit of code which aim is to retrieve a particular Person with the given person_id from the database Person table:
Your system uses a MySQL database or any other relational database such as Oracle RDBMS, Microsoft’s SQL Server, PostgreSQL, or even DB2.
You want to make sure your DAO is working correctly as expected. For the purpose of testing, you might not want to open and hold connections to the actual database because it could be resource intensive. Plus, it can be quite tedious to set up.
Think about it. Every time you want to run a test, you would need to set up your production like MySQL database on your local environment (starting the server etc.) which can be time consuming. And we even haven’t got to the issues we may face if we were running these tests on a CI server during our builds.
So the approach is to use a more lightweight solution in utilising an in-memory database. As its name suggest, the database is in-memory so would be embedded into the application during runtime. And because it’s in-memory, on application shutdown, the database would be teardown completely. This fits into our testing very nicely. When we run our Integration Test (which should ideally be as lightweight as possible, perhaps near as fast as Unit Tests are, but probably not that fast, a tolerable slowness is acceptable), we could easily spin up the in-memory database quickly and populate the required test data just specific for that particular test case and on teardown, the database would be gone. This repeats for every test case. It’s hard to not imagine how clean and easy and isolated it is for each individual Integration Test case.
We’re convinced? Cool, let’s roll on…
First thing first.
Add in the required dependency. There’s quite a number of in-memory database out there on the market in H2, HyperSQL, and Apache Derby.
I’m going to use H2 as apparently it is the most popular amongst users from what i’ve been told.
I mostly use Maven as my build tool and to manage my list of dependencies.
Now we need to configure our tests so that when running our tests, they connect and use the in-memory database instead of the production like MySQL (or any other relational database you would use).
This can be easily done as shown above by having a method that provides the database connection. You can have the above shown method in your test class. You would just write normal JDBC code to connect to a database with the correct connection details (JDBC Driver, JDBC URL) and the credentials as you normally would. But this forms only in your test code.
If you have multiple test classes, then you can easily put above code in an abstract class which all your Integration Test class all extends from.
Then as shown in the DAO code, your Integration Test class can call that method when it interacts with the database.
That’s it. There’s nothing more to it than this. Your test code would be completely separate from your business code. Your business production code would still interact with the MySQL database. It is just that these test cases would work with the in-memory database to ‘prove’ the DAO functionality works as expected.
These in-memory database are popular choices as solutions because they’re:
- Lightweight, hence easy to set up, configure, and use.
- Despite subtle SQL syntax and inner-workings differences, there’s not much between them — they’re very similar in fact.
