ActiveRecord Model Tests are Integration Tests
It’s no longer called the test unit, where you place your tests. It’s called test models.[¹]
The idea behind integration tests is to stress the system under-test end-to-end. Integration tests can seem like a black box in which a single action can trigger many side effects in the application.
ActiveRecord models are integration tests because they make assertions against an external system, the database.
One of the problems of depending on integration tests is that they grow. Increasing the time it takes to run the test suite.
Yes. They run slower. But they also test more things. That’s not a bad thing.[¹]
When too many integration tests exist in a test suite, the feedback loop to coordinate changes increases. More and more resources are needed to run the test suite and build the system.
Data access frameworks such as ActiveRecord provide a mechanism to map an object with a row in a table. The technique might be convenient in some cases. Yet, allowing a data access framework to pass around database rows and tables as objects within a system; Increases coupling between the business rules, use cases, and even the UI.[²]
Separation of concerns is an overarching principle. There’s no relationship between a database table or view and domain logic. Integration tests for these objects make the problem visible at the unit level. There are no boundaries in Ruby on Rails applications because infrastructural logic is mixed with business domain logic.
Database tables are an old and reliable technology. There’s no need to test whether the data will be created, fetched, or validated; we already know it works.
— —
[¹]: David Heinemeier Hansson (2021): RailsConf 2014 — Keynote: Writing Software (https://youtube.com/watch?v=9LfmrkyP81M)
[²]: Robert C. Martin (2018): Clean architecture: a craftsman’s guide to software structure and design(https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure-ebook-dp-B075LRM681/dp/B075LRM681/ref=mt_other?_encoding=UTF8&me=&qid=)
