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.
Outline/structure of the Session
- Mile-high Rails overview for non-Rubyists
- 1000-ft view of our environment
- When to use this approach?
- When not to use this approach?
- Demo: Some code snippets
The talk should give people an introduction to the concept of ActiveModel Inception and enough understanding to both evaluate the pattern for their own use as well as critique it to bring new improvements or alternate approaches.
Ruby automation engineers