Airborne overrides too much of RSpec by default (especially in the Rails context)
Closed this issue · 5 comments
TL;DR: someone used Airborne for an API in a Rails codebase, it broke all other examples for everything else.
We are using multiple API endpoint apps mounted within a larger "shell" app, on a regular basis. The tests for those endpoint apps are contained in the source tree of the "shell". We tried to use Airborne and it works well, for testing one particular application. However, it also messes up things like Rails' requests examples, because it basically takes over basic stuff like get, post and so forth. When you require Airborne, it is an all or nothing affair. Additionally, it violates the convention of having your Rack app defined per example (using a let :app block for example, or using def app helper) by creating a global RSpec config option for setting the app.
So basically, it is very invasive and kinda monky-patchy. Ideally, Airborne should isolate itself to the examples that explicitly want it (and thus can deal with all the various overrides Airborne introduces). RSpec has a facility for this - when you config.include SomeModule you can also pass a metadata matching hash that will only include the module for the examples bearing this metadata. When used in this fashion, you could do
describe 'Some API that gets tested', airborne: true do...
and the require would work for that specific example only. Right now I will have to replicate the entire Airborne bootstrapping file in my source to apply these tweaks.
Another issue is the .configure block - it looks like it is a configuration for Airborne, but it is in fact an alias to RSpec configuration blocks. And this is not something you would necessarily want to call from your examples for instance.
I am more than willing to help with this ;-)
This has not been my experience. In all my Rails apps it uses the Rails requests not the airborne ones. This must be related to your configuration.
Ok - what would the worlfow be to test a different Rack endpoint API application in two different example groups (RSpec files) in the same project? Given that Airborne creates a global RSpec config variable for rack_application (what does this variable even mean in, say, model specs?..)
I never tried it for multiple apps in one project, I guess for that it would be problematic.
The problem is not only "multiple apps in one project", the problem is having anything that uses the get/post/put/patch/request/response methods in tests, i.e. Airborne overrides these methods intrusively. Given the time pressure I had to reimplement the Airborne assertions and request methods that set Content-Type in a tiny library, and seize using the gem altogether. I will close the issue as I have to move on, apologies if this came by surprize.
In a standard rails project it uses the rails get/post/put/patch/request/response not the airborne ones.