pickle 0.4.5 → 0.4.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/Gemfile.lock.development +1 -1
- data/History.txt +8 -1
- data/README.rdoc +112 -0
- data/lib/pickle/version.rb +1 -1
- metadata +3 -3
data/Gemfile.lock.development
CHANGED
data/History.txt
CHANGED
@@ -1,5 +1,12 @@
|
|
1
|
+
== 0.4.6
|
2
|
+
Documentation updates
|
3
|
+
|
4
|
+
* 1 minor improvement
|
5
|
+
* Add email steps documentation to Readme [Michael Moen, Ian White]
|
6
|
+
|
7
|
+
|
1
8
|
== 0.4.5
|
2
|
-
|
9
|
+
Development dependency upgrades
|
3
10
|
|
4
11
|
* 2 minor improvements
|
5
12
|
* Simplify release process, and change Gemspec handling to facilitate faster failing when a development dep becomes incompatible [Ian White]
|
data/README.rdoc
CHANGED
@@ -329,6 +329,117 @@ can build up composite objects with ease
|
|
329
329
|
Given a user exists
|
330
330
|
And a post exists with author: the user # this step will assign the above user as :author on the post
|
331
331
|
|
332
|
+
=== Email Steps
|
333
|
+
|
334
|
+
When you run <tt>rails g pickle --email</tt> you get steps for handling email.
|
335
|
+
|
336
|
+
The general pattern of use is to clear the email queue (if necessary), have your app perform something that sends emails, assert that emails have been delivered, then assert
|
337
|
+
those emails have particular properties.
|
338
|
+
|
339
|
+
For example:
|
340
|
+
|
341
|
+
Background:
|
342
|
+
Given a user has signed up
|
343
|
+
And all emails have been delivered
|
344
|
+
And the user has signed in
|
345
|
+
|
346
|
+
Scenario: User buys a fork
|
347
|
+
Given I am on the fork page
|
348
|
+
And I press "Buy Fork!"
|
349
|
+
Then 1 email should be delivered to the user
|
350
|
+
And the email should contain "You can haz Fork!"
|
351
|
+
When I follow the "my account" link in the email
|
352
|
+
Then I should be on the account page
|
353
|
+
|
354
|
+
And 1 email should be delivered to "sales@example.com"
|
355
|
+
And the email should contain the user's page
|
356
|
+
And the email should contain "User can haz Fork!"
|
357
|
+
|
358
|
+
You can refer to emails that were found in the <tt>Then <i>n</i> emails should be delivered</tt> in the following ways:
|
359
|
+
|
360
|
+
the email (refers to last email)
|
361
|
+
the 1st email
|
362
|
+
the last email
|
363
|
+
email to: "joe@example.com"
|
364
|
+
email subject: "some subject"
|
365
|
+
email to: "joe@example.com", subject: "some subject"
|
366
|
+
|
367
|
+
==== Map expressions to email addresses
|
368
|
+
|
369
|
+
By default a step like
|
370
|
+
|
371
|
+
Then 2 emails should be delivered to the user "Ethel"
|
372
|
+
|
373
|
+
Will look for the <tt>email</tt> attribute on the found model. This is configurable in much the same way as
|
374
|
+
page names for url paths. Have a look at <tt>features/support/email.rb</tt> to add your own custom mappings.
|
375
|
+
|
376
|
+
For example:
|
377
|
+
|
378
|
+
# in features/support/email.rb
|
379
|
+
when /^#{capture_model} sales team$/
|
380
|
+
model!($1).sales_email
|
381
|
+
|
382
|
+
# in a feature
|
383
|
+
Given a site exists
|
384
|
+
And someone buys something form the site
|
385
|
+
Then 1 email should be delivered to the site sales team
|
386
|
+
|
387
|
+
More detail on the emails steps follows:
|
388
|
+
|
389
|
+
==== Given steps
|
390
|
+
|
391
|
+
Clear the email queue, e.g.
|
392
|
+
|
393
|
+
Given all email has been delivered
|
394
|
+
Given all emails have been delivered
|
395
|
+
|
396
|
+
==== When steps
|
397
|
+
|
398
|
+
When <b>[I|they]</b> follow <b>[text_or_regex|the first link]</b> the email, e.g.
|
399
|
+
|
400
|
+
When I follow the first link in the email
|
401
|
+
When I follow "http://example.com/pickle" in the email
|
402
|
+
When I follow "some link text" in the email
|
403
|
+
|
404
|
+
==== Then steps
|
405
|
+
|
406
|
+
Then <b>n</b> email(s) should be delivered to <b>address</b>, e.g.
|
407
|
+
|
408
|
+
Then 1 email should be delivered to joe@example.com
|
409
|
+
|
410
|
+
Then <b>n</b> email(s) should be delivered with <b>fields</b>, e.g.
|
411
|
+
|
412
|
+
Then 2 emails should be delivered with subject: "Welcome to pickle"
|
413
|
+
Then 2 email should be delivered with to: "joe@example.com", from: "pickle@example.com"
|
414
|
+
|
415
|
+
Then <b>fields</b> should be delivered to <b>address</b>, e.g.
|
416
|
+
|
417
|
+
Then subject: "Welcome to pickle" should be delivered to joe@example.com
|
418
|
+
|
419
|
+
Then <b>fields</b> should be not delivered to <b>address</b>, e.g.
|
420
|
+
|
421
|
+
Then subject: "Welcome to pickle" should not be delivered to pickle@example.com
|
422
|
+
|
423
|
+
Then <b>email</b> should have <b>fields</b>, e.g.
|
424
|
+
|
425
|
+
Then the email should have subject: "Welcome to pickle", from: "pickle@example.com"
|
426
|
+
|
427
|
+
Then <b>email</b> should contain "<b>text</b>", e.g.
|
428
|
+
|
429
|
+
Then the email should contain "Thank you for choosing pickle"
|
430
|
+
|
431
|
+
Then <b>email</b> should not contain "<b>text</b>", e.g.
|
432
|
+
|
433
|
+
Then the email should not contain "v1@gr@"
|
434
|
+
|
435
|
+
Then <b>email</b> should link to "<b>href</b>", e.g.
|
436
|
+
|
437
|
+
Then the email should link to http://example.com/pickle
|
438
|
+
|
439
|
+
Then show me the email(s), will open the email(s) in your browser (depends on OS X)
|
440
|
+
|
441
|
+
Then show me the email(s)
|
442
|
+
|
332
443
|
== Run the tests
|
333
444
|
|
334
445
|
To run the specs and features, you can start from the last known good set of gem dependencies in Gemfile.lock.development:
|
@@ -367,3 +478,4 @@ The following people have made Pickle better:
|
|
367
478
|
* {Myron Marston}[http://github.com/myronmarston]
|
368
479
|
* {Stephan Hagemann}[http://github.com/xing]
|
369
480
|
* {Chris Flipse}[http://github.com/cflipse]
|
481
|
+
|
data/lib/pickle/version.rb
CHANGED
metadata
CHANGED