https://github.com/andyw8/rails-controller-playground
https://github.com/andyw8/rails-controller-playground
Last synced: 3 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/andyw8/rails-controller-playground
- Owner: andyw8
- Created: 2014-04-21T13:22:42.000Z (about 11 years ago)
- Default Branch: master
- Last Pushed: 2014-04-21T17:29:16.000Z (about 11 years ago)
- Last Synced: 2025-01-05T19:12:54.784Z (5 months ago)
- Language: Ruby
- Size: 184 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.rdoc
Awesome Lists containing this project
README
{
}[https://travis-ci.org/andyw8/rails-controller-playground]
== README
I've been trying to discover the best way to write controller specs for Rails. I've seen so many different approaches.
Even whether to bother testing Rails controllers or not is controversial. I’m not going to get into that debate here though.
Starting with scaffold generated by rspec-rails, I demonstrate how adapt these so that the database is never hit.
Why write the specs this way?
- It encourages a clean interface between the controller and the model
- The tests are fast
- The spec does not know/care about the implementation of the controller, only its behaviour
- To give myself some practice
Some topics not addressed yet, but perhaps in a future update
- Using Spies instead of expectations
- pros/cons of using `allow_any_instance_of` vs referencing the particular instance
- Is the `be_a_new` matcher useful?
- Additional complexity when using nested resources
- The spec requires that model exists for it to run. This is not ideal if doing GOOS-style outside-in development. May be solvable with `stub_const`.
Please open a pull request if you have a suggestion on how to improve this.