redredred

This should be obvious, but I seem to find myself re-explaining this concept quite a bit. Without testing there can be no Agile development. Tests are not an optional extra, there can be no negotiation. If you are doing agile, you are doing tests. You can test first, my personal preference, or you can test immediately after, but you must write tests.

One of the core values of the Agile manifesto is responding to change over following a plan. Agile development is predicated on writing the simplest solution which meets business requirements and nothing more (YAGNI principle). This can only be done if the developer(s) are able to refactor later as requirements become more complex or change.

Developers will either not refactor at all or take an extremely long time to achieve refactorings if they don’t have tests in place that give them confidence that their changes have not broken existing functionality. No test, no agile. Other features of agile development may or may not be optional, but testing is definitely not.

Powerful ORM frameworks like hibernate and Ibatis and more recently JPA based ORM frameworks like Toplink, Hibernate and openJPA have taken a great deal of drudgery and error prone code out of the average enterprise application codebase. Many IDEs now provide powerful tool support for writing and maintaining code based on these frameworks. One effect of all this has been to move attention away from the database and into code, particularly in instances where developers are using automatic ddl generation from their ORM framework.

In such a situation, developers often don’t think about the effect that changes to their java code are having on the underlying database. Before there has been an initial release this may not necessitate migration of production data, but it can lead to large amounts of time wasted when changes in code necessitate schema changes, particularly if these changes clash with schemas other developers have established in their development environment. After an initial production release it can lead to serious problems if developers alter domain objects which are mapped using ORM frameworks. Simple XML or Annotation changes can wipe out or make redundant whole segments of the production database when released into the wild, or completely alter the semantics of existing data.

There is no doubt that a new discipline is required for developers when writing code using ORM frameworks. Paritcularly where there are multiple developers and potentially multiple production releases (pretty well every agile project I have ever known). This discipline should focus on the database schema that ORM frameworks are generating. Such schemas need to be versioned in the same way as the codebase is versioned. Luckily a tool called Liquibase exist for exactly this problem.

Liquibase provides for the creation and maintanence of database schemas and their data. I have not yet used it to make changes on production databases but we have been using it in development and it has had a very positive effect on productivity as developers no longer have to spend time working out why their tests are no longer working only to eventually discover that it is due to data changes conflicting with their existing schema.

Liquibase manages schemas and data through change sets and the database itself. It stores the change set ids in the database along with a checksum for the change set so that it can determine if the change set has been altered, invalidating it against that database.

With Liquibase in place the database can be generated and/or updated without the use of the ORM frameworks auto generation of DDL, in fact it is essential that this be turned of. For Spring applications a data migrator bean can be configured to automatically generate or update the database on startup of the application context and check that the schema is valid for application data mappings. If this is not desirable Liquibase has Ant targets and Maven goals that can be executed.