Legacy Databases, Testing, and Us

If our legacy application has only a nodding relationship with Rails’ common standards, chances are the database is also a mess. Many issues that plague a legacy database can be frustrating (such as odd naming conventions or unusual use of ActiveRecord features). Still, they don’t affect our ability to test the features.

Databases foreign key constraints

We need to be careful if the database has added constraints that are not evident in the code. Typically, this involves column constraints beyond any validations specified in the ActiveRecord model or foreign key constraints not specified anywhere in the Rails code. Foreign key constraints are the hardest to deal with. Older versions of Rails had no native mechanism for specifying them, but they are beloved by database admins worldwide.

Databases problems

From a testing perspective, the problem is twofold. First, there is business logic outside the Rails code and in the database. That logic is hard to find, test, and change. Even worse, foreign key constraints add dependencies that require certain objects to be created together. In a test environment, that kind of dependency leads to mysterious bugs: the database doesn’t let us create test data, and objects that need to be created have nothing to do with the test but are there only to make the database happy. Keep a close eye on this in a legacy application created by a database-heavy development team that didn’t trust ActiveRecord.