When I started writing High-Performance Java Persistence, I realized I needed a GitHub repository to host all the test cases I needed for the code snippets in my book, and that’s how the high-performance-java-persistence GitHub repository was born.
The high-performance-java-persistence GitHub repository is a collection of integration tests and utilities so that you can test JDBC, JPA, Hibernate and jOOQ features with the utmost ease.
Continue reading “A beginner’s guide to the high-performance-java-persistence GitHub repository”
As previously explained, you can run database integration tests 20 times faster! The trick is to map the data directory in memory, and my previous article showed you what changes you need to do when you have a PostgreSQL or MySQL instance on your machine.
In this post, I’m going to expand the original idea, and show you how you can achieve the same goal using Docker and tmpfs.
Continue reading “How to run integration tests at warp speed using Docker and tmpfs”
In-memory databases such as H2, HSQLDB, and Derby are great to speed up integration tests. Although most database queries can be run against these in-memory databases, many enterprise systems make use of complex native queries which can only be tested against an actual production-like relational database.
In this post, I’m going to show you how you can run PostgreSQL and MySQL integration tests almost as fast as any in-memory database.
Continue reading “How to run database integration tests 20 times faster”
Unit testing requires isolating individual components from their dependencies. Dependencies are replaced with mocks, which simulate certain use cases. This way, we can validate the in-test component behavior across various external context scenarios.
Web components can be unit tested using mock business logic services. Services can be tested against mock data access repositories. But the data access layer is not a good candidate for unit testing because database statements need to be validated against an actual running database system.
Integration testing database options
Ideally, our tests should run against a production-like database. But using a dedicated database server is not feasible, as we most likely have more than one developer to run such integration test-suites. To isolate concurrent test runs, each developer would require a dedicated database catalog. Adding a continuous integration tool makes matters worse since more tests would have to be run in parallel.
Lesson 1: We need a forked test-suite bound database
When a test suite runs, a database must be started and only made available to that particular test-suite instance. Basically we have the following options:
- An in-memory embedded database
- A temporary spawned database process
Continue reading “Integration testing done right with Embedded MongoDB”