When automating against a Rails application, it can become cumbersome to keep up the the data model that the developers are using. When you experience rapid growth, software changes quickly to adapt to the business needs, and automation needs to keep up.
We use a glassbox approach to testing. That is, set-up and tear-down tasks include database access to create and destroy test data for the purpose of targeted automated testing. Previously, we relied on low-level direct access to the db. As a result, automation began to introduce bad data that hampered migrations and worse.
Our solution to this, since the developers do not have the bandwidth to provide us a robust API, is what we call ActiveModel Inception. We import the Rails application into our test harness as a git submodule, implement ActiveSupport and ActiveRecord, some glue code, and use the application Models directly so that we can benefit from the safety and ease of use of the Rails models, including all validations and associations.
This approach, of course, has several pitfalls. If you have multiple interdependent Rails products, testing across multiple products becomes increasingly difficult using this approach. Although the unique benefits and constraints of our situation makes this our favored approach for now, we have identified a path for next steps toward solving that limitation.