JARB in practice

In a project we recently started, we introduced a 100% test-driven code coverage philosophy, including Selenium 2 tests for automated acceptance tests. As usual and expected, the development, refactorings and changes of insights in this project are handled neatly, because of the control the team has over the codebase. Robert Martin is not mistaken in his Clean Coder when he presses for 100% code coverage. This really is the way to go.


What was new in this project for our development team is the introduction of JARB. The promise of JARB is more alignment between database and application, better maintainability and earlier detection of database- or mapping-related errors.

Does JARB deliver? The answer is a solid YES. We reap all the benefits we expected from it. The product has some refurbishing which needs to be done, again expected feedback from trying out a product like JARB in a real-life situation. But basically, by allowing database-related tests to be set up in an early stage more bugs get squashed in the unit testing stage. By the developer, at a time when a bug is still relatively cheap to squash.

So to recap, this is what we see from JARB:

  • database constraint violations can be relied on, because their violations get mapped to proper Java exceptions—gone are the days of complex and error-prone Java validators that duplicate database functionality

  • validation logic can be partially reused from the database—no more duplicated validation logic, both in application, database and frontend

  • unit tests can be run from the schema as it will run in a production environment—enjoy all the real database schema advantages over the over-simplified Hibernate generated schema

  • synchronize model and database structure—no more separate developer and database administrator processeses for respectively changing model and database, but merge them into one

  • testdata checked against the current model—testdata out of sync? the test suite will fail a unit test and give immediate feedback where it can be fixed the fastest; on the laptop of the developer

  • testdata maintainable by non-developers—Excel-based testdata is something users can relate to quickly and adopt easily


If you want to give JARB a try for your own project or just have a look, check it out at https://github.com/42BV/jarb.

JARB has sprouted from our philosophy about quality. We believe strongly that detecting errors as early as possible not only lowers the cost of software development considerably, but has an integrally positive effect on the quality of the product in general.

On September 22nd, 42 is hosting a Quality Seminar (in dutch) with the goal of disseminating and sharing information about the value of quality in the software development process. For more information, go to http://seminar.42.nl/quality/