cypress-rails 0.1.0 → 0.1.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/Gemfile.lock +1 -1
- data/README.md +68 -79
- data/lib/cypress-rails/launches_cypress.rb +3 -0
- data/lib/cypress-rails/version.rb +1 -1
- data/script/test_example_app +1 -0
- metadata +1 -1
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: c10c202bcac81adf32af13a29cdbfde32a2d944682d8861697974315d93b9736
|
4
|
+
data.tar.gz: 6bbbe194f98a68083eed91f9afe9f8d3ffb2b7614e5693729a6d850f1b2fb443
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 81e80ecb7397220ed6f4ab28d8d61136ebfc942c21499b6b0baea4b11ecf63d7b316b51d1cf91c5d44dbd6be00160dace8dcd2b1a1a4018d5fabe44934ab3c36
|
7
|
+
data.tar.gz: 0f74877fc5882dddfe2deec98f22d20296a2db572a83bd162649a13f64d4767810f52da1abd923c87ea849662b3e82ab04c8c4dba0a6457379a1c1f35bb067e4
|
data/Gemfile.lock
CHANGED
data/README.md
CHANGED
@@ -7,70 +7,6 @@ This is a simple gem to make it easier to start writing browser tests with
|
|
7
7
|
regardless of whether your app is server-side rendered HTML, completely
|
8
8
|
client-side JavaScript, or something in-between.
|
9
9
|
|
10
|
-
## Why do this?
|
11
|
-
|
12
|
-
Rails ships with a perfectly competent browser-testing facility called [system
|
13
|
-
tests](https://guides.rubyonrails.org/testing.html#system-testing) which depend
|
14
|
-
on [capybara](https://github.com/teamcapybara/capybara) to drive your tests,
|
15
|
-
most often with [Selenium](https://www.seleniumhq.org). All of these tools work,
|
16
|
-
are used by lots of people, and are a perfectly reasonable choice when writing
|
17
|
-
full-stack tests of your Rails application.
|
18
|
-
|
19
|
-
So why would you go off the Rails to use Cypress and this gem, adding two
|
20
|
-
additional layers to the Jenga tower of testing facilities that Rails ships
|
21
|
-
with? Really, it comes down to the potential for an improved development
|
22
|
-
experience. In particular:
|
23
|
-
|
24
|
-
* Cypress's [IDE-like `open`
|
25
|
-
command](https://docs.cypress.io/guides/getting-started/writing-your-first-test.html#Add-a-test-file)
|
26
|
-
provides a highly visual, interactive, inspectable test runner. Not only can
|
27
|
-
you watch each test run and read the commands as they're executed, Cypress
|
28
|
-
takes a DOM snapshot before and after each command, which makes rewinding and
|
29
|
-
inspecting the state of the DOM trivially easy, something that I regularly
|
30
|
-
find myself losing 20 minutes attempting to do with Capybara
|
31
|
-
* `cypress open` enables an almost REPL-like feedback loop that is much faster
|
32
|
-
and more information dense than using Capybara and Selenium. Rather than
|
33
|
-
running a test from the command line, seeing it fail, then adding a debug
|
34
|
-
breakpoint to a test to try to manipulate the browser or tweaking a call to a
|
35
|
-
Capybara API method, failures to be rather obvious when using Cypress and
|
36
|
-
fixing it is usually as easy as tweaking a command, hitting save, and watching
|
37
|
-
it re-run
|
38
|
-
* With very few exceptions, a Cypress test that works in a browser window will
|
39
|
-
also pass when run headlessly in CI
|
40
|
-
* Cypress selectors are [just jQuery
|
41
|
-
selectors](https://api.jquery.com/category/selectors/), which makes them both
|
42
|
-
more familiar and more powerful than the CSS and XPath selectors offered by
|
43
|
-
Capybara. Additionally, Cypress makes it very easy to drop into a plain
|
44
|
-
synchronous JavaScript function for [making more complex
|
45
|
-
assertions](https://docs.cypress.io/guides/references/assertions.html#Should-callback)
|
46
|
-
or composing repetitive tasks into [custom
|
47
|
-
commands](https://docs.cypress.io/api/cypress-api/custom-commands.html#Syntax#article)
|
48
|
-
* Cypress commands are, generally, much faster than analogous tasks in Selenium.
|
49
|
-
Where certain clicks and form inputs will hang for 300-500ms for seemingly no
|
50
|
-
reason when running against Selenium WebDriver, Cypress commands tend to run
|
51
|
-
as fast as jQuery can select and fill an element (which is, of course, pretty
|
52
|
-
fast)
|
53
|
-
* By default, Cypress [takes a
|
54
|
-
video](https://docs.cypress.io/guides/guides/screenshots-and-videos.html#Screenshots#article)
|
55
|
-
of every headless test run, taking a lot of the mystery (and subsequent
|
56
|
-
analysis & debugging) out of test failures in CI
|
57
|
-
|
58
|
-
Nevertheless, there are trade-offs to attempting this (most notably around
|
59
|
-
Cypress's [limited browser
|
60
|
-
support](https://docs.cypress.io/guides/guides/launching-browsers.html#Browsers)
|
61
|
-
and the complications to test data management), and I wouldn't recommend
|
62
|
-
adopting Cypress and writing a bunch of browser tests for every application.
|
63
|
-
But, if the above points sound like solutions to problems you experience, you
|
64
|
-
might consider trying it out.
|
65
|
-
|
66
|
-
## Installation
|
67
|
-
|
68
|
-
**tl;dr**:
|
69
|
-
|
70
|
-
1. Install the npm package `cypress`
|
71
|
-
2. Install this gem `cypress-rails`
|
72
|
-
3. Run `rake cypress:init`
|
73
|
-
|
74
10
|
### Installing Cypress itself
|
75
11
|
|
76
12
|
The first step is making sure Cypress is installed (that's up to you, this
|
@@ -123,13 +59,7 @@ When using Rails, however, you'll also want your Rails test server to be running
|
|
123
59
|
so that there's something for Cypress to interact with. `cypress-rails` provides
|
124
60
|
a wrapper for running `cypress open` with a dedicated Rails test server.
|
125
61
|
|
126
|
-
So, by running
|
127
|
-
|
128
|
-
```
|
129
|
-
$ cypress-rails open
|
130
|
-
```
|
131
|
-
|
132
|
-
Or:
|
62
|
+
So, by running:
|
133
63
|
|
134
64
|
```
|
135
65
|
$ rake cypress:open
|
@@ -143,13 +73,7 @@ itself.
|
|
143
73
|
### Run tests headlessly with `cypress run`
|
144
74
|
|
145
75
|
To run your tests headlessly (e.g. when you're in CI), you'll want the `run`
|
146
|
-
command
|
147
|
-
|
148
|
-
```
|
149
|
-
$ cypress-rails run
|
150
|
-
```
|
151
|
-
|
152
|
-
Or, with rake:
|
76
|
+
command:
|
153
77
|
|
154
78
|
```
|
155
79
|
$ rake cypress:run
|
@@ -266,7 +190,7 @@ pollute other test suites or scripts, you can use the `before_server_stop` to
|
|
266
190
|
of your test database. To set up the hook, pass a block to
|
267
191
|
`CypressRails.hooks.before_server_stop`.
|
268
192
|
|
269
|
-
|
193
|
+
## Setting up continuous integration
|
270
194
|
|
271
195
|
#### Circle CI
|
272
196
|
|
@@ -317,3 +241,68 @@ jobs:
|
|
317
241
|
- run: bin/rake cypress:run
|
318
242
|
```
|
319
243
|
|
244
|
+
## Why use this?
|
245
|
+
|
246
|
+
Rails ships with a perfectly competent browser-testing facility called [system
|
247
|
+
tests](https://guides.rubyonrails.org/testing.html#system-testing) which depend
|
248
|
+
on [capybara](https://github.com/teamcapybara/capybara) to drive your tests,
|
249
|
+
most often with [Selenium](https://www.seleniumhq.org). All of these tools work,
|
250
|
+
are used by lots of people, and are a perfectly reasonable choice when writing
|
251
|
+
full-stack tests of your Rails application.
|
252
|
+
|
253
|
+
So why would you go off the Rails to use Cypress and this gem, adding two
|
254
|
+
additional layers to the Jenga tower of testing facilities that Rails ships
|
255
|
+
with? Really, it comes down to the potential for an improved development
|
256
|
+
experience. In particular:
|
257
|
+
|
258
|
+
* Cypress's [IDE-like `open`
|
259
|
+
command](https://docs.cypress.io/guides/getting-started/writing-your-first-test.html#Add-a-test-file)
|
260
|
+
provides a highly visual, interactive, inspectable test runner. Not only can
|
261
|
+
you watch each test run and read the commands as they're executed, Cypress
|
262
|
+
takes a DOM snapshot before and after each command, which makes rewinding and
|
263
|
+
inspecting the state of the DOM trivially easy, something that I regularly
|
264
|
+
find myself losing 20 minutes attempting to do with Capybara
|
265
|
+
* `cypress open` enables an almost REPL-like feedback loop that is much faster
|
266
|
+
and more information dense than using Capybara and Selenium. Rather than
|
267
|
+
running a test from the command line, seeing it fail, then adding a debug
|
268
|
+
breakpoint to a test to try to manipulate the browser or tweaking a call to a
|
269
|
+
Capybara API method, failures to be rather obvious when using Cypress and
|
270
|
+
fixing it is usually as easy as tweaking a command, hitting save, and watching
|
271
|
+
it re-run
|
272
|
+
* With very few exceptions, a Cypress test that works in a browser window will
|
273
|
+
also pass when run headlessly in CI
|
274
|
+
* Cypress selectors are [just jQuery
|
275
|
+
selectors](https://api.jquery.com/category/selectors/), which makes them both
|
276
|
+
more familiar and more powerful than the CSS and XPath selectors offered by
|
277
|
+
Capybara. Additionally, Cypress makes it very easy to drop into a plain
|
278
|
+
synchronous JavaScript function for [making more complex
|
279
|
+
assertions](https://docs.cypress.io/guides/references/assertions.html#Should-callback)
|
280
|
+
or composing repetitive tasks into [custom
|
281
|
+
commands](https://docs.cypress.io/api/cypress-api/custom-commands.html#Syntax#article)
|
282
|
+
* Cypress commands are, generally, much faster than analogous tasks in Selenium.
|
283
|
+
Where certain clicks and form inputs will hang for 300-500ms for seemingly no
|
284
|
+
reason when running against Selenium WebDriver, Cypress commands tend to run
|
285
|
+
as fast as jQuery can select and fill an element (which is, of course, pretty
|
286
|
+
fast)
|
287
|
+
* By default, Cypress [takes a
|
288
|
+
video](https://docs.cypress.io/guides/guides/screenshots-and-videos.html#Screenshots#article)
|
289
|
+
of every headless test run, taking a lot of the mystery (and subsequent
|
290
|
+
analysis & debugging) out of test failures in CI
|
291
|
+
|
292
|
+
Nevertheless, there are trade-offs to attempting this (most notably around
|
293
|
+
Cypress's [limited browser
|
294
|
+
support](https://docs.cypress.io/guides/guides/launching-browsers.html#Browsers)
|
295
|
+
and the complications to test data management), and I wouldn't recommend
|
296
|
+
adopting Cypress and writing a bunch of browser tests for every application.
|
297
|
+
But, if the above points sound like solutions to problems you experience, you
|
298
|
+
might consider trying it out.
|
299
|
+
|
300
|
+
## Installation
|
301
|
+
|
302
|
+
**tl;dr**:
|
303
|
+
|
304
|
+
1. Install the npm package `cypress`
|
305
|
+
2. Install this gem `cypress-rails`
|
306
|
+
3. Run `rake cypress:init`
|
307
|
+
|
308
|
+
|
data/script/test_example_app
CHANGED