Following is an enumeration of the problems that we experienced on a daily basis:
- the schema being created by HBM2DDL ‘create’ is deviant from the real schema
- column information (type, length, nullable etc) from the database is being duplicated in the Java model and the client
- constraint violations from the database are not properly mapped to Java exceptions
- SQL import files are hard to keep in sync with model changes
More nefariously, these problems mean that it is not possible to test conditions as early as possible, ie during the unit tests. If you subscribe to the vision of Boehm’s Curve, you will accept the premisse that a defect needs to be caught as early as possible to reduce total cost of ownership considerably. At 42 we are pushing the envelope in forcing as many defect findings as we can towards the unit tests.
Note that we like the idea of working with in-memory databases, so that we have fast feedback cycles and can always run a single unit test without having to do manual setup/teardown activities. HSQLDB 2.1, in that sense, became a lot better with the improved constraint violation feedback and opened the door for proper constraint violation mapping to exceptions.
We found out that the following elements are not adopted as part of an early test run:
- schema changes are not tested
- constraint violations are not tested
- column constraint checks are not tested
- SQL import files are not tested for being up-to-date
- usage of database views is not tested
- complex data setups for tests are passed by in favor of irrelevant mock tests
Project JARB (JAva Repository Bridge) aims to fix these problems. It ties together a number of ideas in this field in one umbrella project. In a couple of posts before this, you can read about the ideas behind our usage of Liquibase, the technical guide to doing this and the idea behind our Excel testdata module. Note that JARB builds on JPA, because it utilizes the relations already figured out by JPA.
What JARB will allow you to do, is the following:
- provide your test data through your persistence layer (effectively testing it) using an Excel datafeed. You can also feed your existing database into Excel. the feed can be kept up-to-date with an easy to connect to unit test. You can throw import.sql away!
- integrate with Liquibase for test runs; you can use the Liquibase schema creation for your unit tests; degrade HBM2DDL from ‘create’ to ‘validate’. As an added bonus, you can use your database to its fullest potential: you are no longer restricted to only tables, but you can use views, custom functions, etc.
- map specific database constraint violations to your own exceptions and connect with a unit test that keeps the mapping in sync with the existing constraints.
- use database column information to supplement JSR-303 validation and unlock this information for frontends as well. It is no longer necessary to duplicate this information in model annotations (both JPA and JSR-303) and frontend validations.
All of these together have a powerful impact on your options for Test Driven Development. No longer are you confined to testing database impact manually (by deploying the app and clicking through it), or even in a later test environment. You can now make communication with the database a worthy first-class citizen of the test suite.
In the coming time, more articles will be published that explain more of JARB and how you can make it work for your own projects.
Note: we are currently still merging our code into the github repository. On monday evening we expect to have all components available.