|
3 | 3 | `rspec-rails` brings the [RSpec][] testing framework to [Ruby on Rails][]
|
4 | 4 | as a drop-in alternative to its default testing framework, Minitest.
|
5 | 5 |
|
6 |
| -In RSpec, tests are not just scripts that verify your application code; |
7 |
| -they’re also detailed explanations of how the application is supposed to behave, |
8 |
| -expressed in plain English—in other words, _specs._ |
| 6 | +In RSpec, tests are not just scripts that verify your application code. |
| 7 | +They’re also detailed explanations of how the application is supposed to behave, |
| 8 | +expressed in plain English; in other words, _specs._ |
9 | 9 |
|
10 | 10 | Use **[`rspec-rails` 1.x][]** for Rails 2.x.
|
11 | 11 |
|
@@ -37,6 +37,9 @@ Use **[`rspec-rails` 1.x][]** for Rails 2.x.
|
37 | 37 | end
|
38 | 38 | ```
|
39 | 39 |
|
| 40 | + (Adding it to the `:development` group is not strictly necessary, |
| 41 | + but without it, generators and rake tasks must be preceded by `RAILS_ENV=test`.) |
| 42 | + |
40 | 43 | 2. Then, in your project directory:
|
41 | 44 |
|
42 | 45 | ```sh
|
@@ -290,26 +293,32 @@ and the expectations revolve around page content.
|
290 | 293 |
|
291 | 294 | Because system specs are a wrapper around Rails’ built-in `SystemTestCase`,
|
292 | 295 | they’re only available on Rails 5.1+.
|
| 296 | +(Feature specs serve the same purpose, but without this dependency.) |
293 | 297 |
|
294 | 298 | #### Feature specs
|
295 | 299 |
|
296 |
| -Feature specs serve the same purpose, |
297 |
| -but `SystemTestCase` solves some longstanding configuration issues they had, |
298 |
| -so the RSpec team [officially recommends system specs][] over feature specs. |
| 300 | +Before Rails introduced system testing facilities, |
| 301 | +feature specs were the only spec type for end-to-end testing. |
| 302 | +While the RSpec team now [officially recommends system specs][] instead, |
| 303 | +feature specs are still fully supported, look basically identical, |
| 304 | +and work on older versions of Rails. |
| 305 | + |
| 306 | +On the other hand, feature specs require non-trivial configuration |
| 307 | +to get some important features working, |
| 308 | +like JavaScript testing or making sure each test runs with a fresh DB state. |
| 309 | +With system specs, this configuration is provided out-of-the-box. |
299 | 310 |
|
300 |
| -If you don’t have the luxury of upgrading, |
301 |
| -there’s no problem with using feature specs instead. |
302 |
| -Be sure to add [Capybara][] to the `:test` group of your `Gemfile` first: |
| 311 | +Like system specs, feature specs require the [Capybara][] gem. |
| 312 | +Rails 5.1+ includes it by default as part of system tests, |
| 313 | +but if you don’t have the luxury of upgrading, |
| 314 | +be sure to add it to the `:test` group of your `Gemfile` first: |
303 | 315 |
|
304 | 316 | ```ruby
|
305 | 317 | group :test do
|
306 | 318 | gem "capybara"
|
307 | 319 | end
|
308 | 320 | ```
|
309 | 321 |
|
310 |
| -(It’s actually required for both feature and system specs, |
311 |
| -but Rails includes it by default in versions 5.1+.) |
312 |
| - |
313 | 322 | [officially recommends system specs]: http://rspec.info/blog/2017/10/rspec-3-7-has-been-released/#rails-actiondispatchsystemtest-integration-system-specs
|
314 | 323 | [Capybara]: https://github.com/teamcapybara/capybara
|
315 | 324 |
|
|
0 commit comments