Hello,
it is seems quite easy to forget to disable ‘forgery_protection’ when testing with request specs, since everything just works, the only way to notice is to verify with curl which is a little bit tedious.
I’m thinking that we should introduce one more type of spec’s, such as public_request/ or just api/ pre-configured:
ActionController::Base.allow_forgery_protection = true
Is there a rule of thumbs you’re using when TDD’ing public API’s?
Thanks in advance.
ok, got it, just looked into the Learn code 
Having different class for the APIs seems like a fair convention, however it doesn’t answer my question and I still don’t feel confidence about that, i.e. what if someone accidentally switch protect_from_forger to with :exception in that base class? CI won’t show me difference and will let it go to production.
I’ve never felt the need to test this explicitly. However, could you have a test that asserts that your base API controller has allow_forgery_protection set to false?
Something like expect(ApiController.allow_forgery_protection).to be_false?
thank you @benorenstein, good point, however this still leaves some concerns, for example someone might use different base class accidentally and the test won’t fail…
I believe the following line in the ..environments/test.rb is unnecessary:
# Disable request forgery protection in test environment.
config.action_controller.allow_forgery_protection = false
since it cause some false positives and worst can drive design the wrong direction
For the fairness, I been caught into this trap about a half year ago and that wasn’t the first time, now when I need to implement public API on the existent application my considerations is driven by my experience, not tests. So, using the chance, I’d love to dive into the topic a little bit deeper 