{"id":17086418,"url":"https://github.com/dasch/system-testing-example","last_synced_at":"2026-05-06T22:10:14.030Z","repository":{"id":3755613,"uuid":"4831377","full_name":"dasch/system-testing-example","owner":"dasch","description":null,"archived":false,"fork":false,"pushed_at":"2012-06-29T11:26:25.000Z","size":104,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-01-28T20:41:55.793Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dasch.png","metadata":{"files":{"readme":"README","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2012-06-29T11:03:24.000Z","updated_at":"2014-06-01T11:41:45.000Z","dependencies_parsed_at":"2022-09-13T10:10:46.386Z","dependency_job_id":null,"html_url":"https://github.com/dasch/system-testing-example","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dasch%2Fsystem-testing-example","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dasch%2Fsystem-testing-example/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dasch%2Fsystem-testing-example/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dasch%2Fsystem-testing-example/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dasch","download_url":"https://codeload.github.com/dasch/system-testing-example/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245115408,"owners_count":20563158,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-14T13:28:35.893Z","updated_at":"2026-05-06T22:10:08.985Z","avatar_url":"https://github.com/dasch.png","language":"Ruby","funding_links":[],"categories":[],"sub_categories":[],"readme":"An example of system level testing\n==================================\n\nWhile very simplistic, this provides a basic example of a system-level\nintegration test using RSpec, Capybara and Poltergeist.\n\nThe system is specified in the Procfile. It consists of two apps, `auth` and\n`toots`, as well as an Nginx web server. The test, `features/tooting_spec.rb`,\nstarts Foreman in a separate process, runs Capybara against the Nginx\ninstance, and shuts down Foreman afterwards.\n\nRun the specs with\n\n    rspec features\n\nThe test itself is pretty stupid, and could use some abstractions, but this is\nthe basic idea.\n\nThe technique of course becomes more interesting as soon as other services\nsuch as Solr and Redis come into the mix. I imagine one could even boot a\nsimple mail server and client and do complete integration testing of e-mail\nscenarios such as:\n\n    When I register as a user\n    Then I should receive a confirmation e-mail\n\n    When I click the link in the confirmation e-mail\n    Then my user account should be confirmed\n\n\nIssues\n------\n\nYou'll quickly run into issues with Bundler. Say you run the specs with\n`bundle exec rspec features`, but your Procfile looks like this:\n\n    foo: bundle exec ruby foo.rb\n    bar: cd vendor/bar \u0026\u0026 bundle exec ruby bar.rb\n\nThat is, \"foo\" and \"bar\" have different Gemfiles. While \"foo\" may share its\nbundle with Foreman, \"bar\" may not. Because Foreman is started from within\n`bundle exec` though, both \"foo\" and \"bar\" will inherit the bundle, regardless\nof the fact that \"bar\" is run with `bundle exec` in a different directory\nthat has its own Gemfile. So far the only solution I have found is to *not*\nrun the specs with `bundle exec`, but to instead do `require \"bundler/setup\"`\nin the spec (or spec helper) *after* forking the Foreman process. If you had\nany insight into how to make that easier, I'd love some feedback.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdasch%2Fsystem-testing-example","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdasch%2Fsystem-testing-example","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdasch%2Fsystem-testing-example/lists"}