Standardize line breaks in datetime tests

Co-authored-by: Jonathan Wren <jonathan@nowandwren.com>
This commit is contained in:
Micah Jerome Ellison 2021-02-23 20:11:26 -08:00 committed by Jonathan Wren
parent 40a1a871cb
commit 5ad5bac786

View file

@ -104,6 +104,7 @@ Feature: Reading and writing to journal with custom date formats
| sunday: entry on a sunday | entry on a sunday | sunday at 9am | | sunday: entry on a sunday | entry on a sunday | sunday at 9am |
| sUndAy: entry on a sunday | entry on a sunday | sunday at 9am | | sUndAy: entry on a sunday | entry on a sunday | sunday at 9am |
Scenario Outline: Create entry using day of the week as entry date. Scenario Outline: Create entry using day of the week as entry date.
Given we use the config "simple.yaml" Given we use the config "simple.yaml"
When we run "jrnl <command>" When we run "jrnl <command>"
@ -124,12 +125,14 @@ Feature: Reading and writing to journal with custom date formats
| sun: entry on a sunday | entry on a sunday | sunday at 9am | | sun: entry on a sunday | entry on a sunday | sunday at 9am |
| sUn: entry on a sunday | entry on a sunday | sunday at 9am | | sUn: entry on a sunday | entry on a sunday | sunday at 9am |
Scenario: Journals with unreadable dates should still be loaded Scenario: Journals with unreadable dates should still be loaded
Given we use the config "unreadabledates.yaml" Given we use the config "unreadabledates.yaml"
When we run "jrnl -2" When we run "jrnl -2"
Then the output should contain "I've lost track of time." Then the output should contain "I've lost track of time."
And the output should contain "Time has no meaning." And the output should contain "Time has no meaning."
Scenario: Journals with readable dates AND unreadable dates should still contain all data. Scenario: Journals with readable dates AND unreadable dates should still contain all data.
Given we use the config "mostlyreadabledates.yaml" Given we use the config "mostlyreadabledates.yaml"
When we run "jrnl --short" When we run "jrnl --short"
@ -138,17 +141,20 @@ Feature: Reading and writing to journal with custom date formats
2019-07-18 14:23 The first entry 2019-07-18 14:23 The first entry
2019-07-19 14:23 The second entry 2019-07-19 14:23 The second entry
Scenario: Update near-valid dates after journal is edited Scenario: Update near-valid dates after journal is edited
Given we use the config "mostlyreadabledates.yaml" Given we use the config "mostlyreadabledates.yaml"
When we run "jrnl 2222-08-19: I have made it exactly one month into the future." When we run "jrnl 2222-08-19: I have made it exactly one month into the future."
When we run "jrnl -2" When we run "jrnl -2"
Then the output should contain "2019-07-19 14:23 The second entry" Then the output should contain "2019-07-19 14:23 The second entry"
Scenario: Integers in square brackets should not be read as dates Scenario: Integers in square brackets should not be read as dates
Given we use the config "brackets.yaml" Given we use the config "brackets.yaml"
When we run "jrnl -1" When we run "jrnl -1"
Then the output should contain "[1] line starting with 1" Then the output should contain "[1] line starting with 1"
# broken still # broken still
@skip @skip
Scenario: Dayone entries without timezone information are interpreted in current timezone Scenario: Dayone entries without timezone information are interpreted in current timezone
@ -157,6 +163,7 @@ Feature: Reading and writing to journal with custom date formats
Then we should get no error Then we should get no error
And the output should contain "2013-01-17T18:37Z" in the local time And the output should contain "2013-01-17T18:37Z" in the local time
Scenario: Loading entry with ambiguous time stamp in timezone-aware journal (like Dayone) Scenario: Loading entry with ambiguous time stamp in timezone-aware journal (like Dayone)
#https://github.com/jrnl-org/jrnl/issues/153 #https://github.com/jrnl-org/jrnl/issues/153
Given we use the config "bug153.yaml" Given we use the config "bug153.yaml"