Super-easy way to start up a dependent Rails app (say, an API server) in a consumer's acceptance tests
lib | ||
.gitignore | ||
Gemfile | ||
LICENSE | ||
Rakefile | ||
README.md | ||
vegetable_glue.gemspec |
VegetableGlue
Easy way to start/stop/restart a dependent Rails API app in a consumer's acceptance tests.
Uses database_cleaner
's :truncation
mode to clean out your databases after each run.
Installation & Usage
In both apps' Gemfiles:
gem 'vegetable_glue'
In the provider (API):
- Create or use a Rails environment that has a database that you don't mind nuking (say
test
,acceptance
, orcucumber
) - Modify
config/routes.rb
:
require 'vegetable_glue/routes'
MyApp::Application.routes.draw do
# ... your other routes ...
acceptance_helper_routes #=> for the :acceptance env, or
acceptance_helper_routes_for :cucumber #=> for the :cucumber env
end
The two additional routes are only added in that environment.
In the consumer (Frontend):
- For Cucumber, add the following to
features/support/env.rb
:
require 'vegetable_glue/cucumber'
- Then add this to the
config/environments/<environment>.rb
file that Cucumbers runs under:
require 'vegetable_glue'
VegetableGlue.url = 'http://localhost:6161/' #=> include the port in here, too, that's where the app will run
VegetableGlue.path = '../path/to/the/app'
The app will clean its database on each scenario. To restart the app, pass in the environment variable REGLUE
:
REGLUE=true bundle exec cucumber
Or, use one of the Rake tasks: vegetable:unglue
to shut down and vegetable:reglue
to shutdown, then clean.
If you're using ActiveResource, a good source of the URL is ActiveResource::Base.site
.
Contributing
- Fork it
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Added some feature'
) - Push to the branch (
git push origin my-new-feature
) - Create new Pull Request