https://github.com/dasch/system-testing-example

https://github.com/dasch/system-testing-example

Last synced: 24 days ago
JSON representation

• Host: GitHub
• URL: https://github.com/dasch/system-testing-example
• Owner: dasch
• Created: 2012-06-29T11:03:24.000Z (over 12 years ago)
• Default Branch: master
• Last Pushed: 2012-06-29T11:26:25.000Z (over 12 years ago)
• Last Synced: 2023-04-11T15:32:56.263Z (over 1 year ago)
• Language: Ruby
• Size: 102 KB
• Stars: 1
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README

Awesome Lists containing this project

README

        
An example of system level testing

==================================

While very simplistic, this provides a basic example of a system-level

integration test using RSpec, Capybara and Poltergeist.

The system is specified in the Procfile. It consists of two apps, `auth` and

`toots`, as well as an Nginx web server. The test, `features/tooting_spec.rb`,

starts Foreman in a separate process, runs Capybara against the Nginx

instance, and shuts down Foreman afterwards.

Run the specs with

    rspec features

The test itself is pretty stupid, and could use some abstractions, but this is

the basic idea.

The technique of course becomes more interesting as soon as other services

such as Solr and Redis come into the mix. I imagine one could even boot a

simple mail server and client and do complete integration testing of e-mail

scenarios such as:

    When I register as a user

    Then I should receive a confirmation e-mail

    When I click the link in the confirmation e-mail

    Then my user account should be confirmed

Issues

------

You'll quickly run into issues with Bundler. Say you run the specs with

`bundle exec rspec features`, but your Procfile looks like this:

    foo: bundle exec ruby foo.rb

    bar: cd vendor/bar && bundle exec ruby bar.rb

That is, "foo" and "bar" have different Gemfiles. While "foo" may share its

bundle with Foreman, "bar" may not. Because Foreman is started from within

`bundle exec` though, both "foo" and "bar" will inherit the bundle, regardless

of the fact that "bar" is run with `bundle exec` in a different directory

that has its own Gemfile. So far the only solution I have found is to *not*

run the specs with `bundle exec`, but to instead do `require "bundler/setup"`

in the spec (or spec helper) *after* forking the Foreman process. If you had

any insight into how to make that easier, I'd love some feedback.