Historical errata for Effective Testing with RSpec 3

“other forms of docuemntation” should be “documentation”

“idenfity which text” should be “identify”

In chapter 5: the text says “The POST route needs to check the succeeded? flag of the RecordResult and set the HTTP status and body accordingly. Open up app/api.rb and change the post ’/expenses’ route to the following”

But the code checks for #success?, not #suceeded?.

Paragraph 4, line 2 :
and type the the code in on your computer
—> twice the and in on (?)

Page 3 Getting Started With Spec, paragraph 3, second point :
Safety net: finding errors in your code before your customers do
—> missing period at the end of sentence

First line : Now that you’re moved
—> I’m not anglophone, but I would expect : Now that you have moved

Forget it, there is nowhere in the book periods after indented paragraphs, except the second to last paragraph on this page :
dependencies, slow tests, and incomplete work.

Section Running Just What You Need, second paragraph, end of first line : you’ll want to to run just
—> twice to

Top of page after « truncated », I would leave the sub-title
—> Failed examples:
to better identify the location of “the end of the spec output”. In my case, after the failures, I have several pages of output starting with :
no spec file location in {:block=>#<Proc:0x007f87ccdaaf88@/

“You don’t need to know anything about Bundler to follow along, but we won’t be explaining it in depth.” I’m not sure the “but” makes sense in this context, because a contrast isn’t being drawn. Maybe a “so”?

“Testers tend to refer to them as mocks, stubs, dummies, or spies, depending on how they are used. Martin Fowler’s article “Test Doubles” explains the nuances. RSpec supports all of these uses under the umbrella term of doubles." Dummies aren’t actually mentioned later in the book when types of RSpec doubles are described, so I wonder if it makes sense to not mention them here either.

“Since you’ll need to access this phony Ledger instance from all of your specs, you’ll capture it using a let construct, just like you did with the app object in the previous chapter.” I couldn’t find a place where the app object was stored in a let construct in the previous chapter; maybe this sentence was left over from a previous version of the code.

“You’ll want to create separate databases in SQLite for testing and production (so that you don’t clobber your real data during testing).”

Typically I’d think of a development/testing contrast here, rather than a testing/production. And later the book does load data into the development database, not production.

“We want to tell the recorder to save the expense…” This might have been meant to be “ledger”—there is a “record” method, but not a “recorder” (unless we’re naming duck types, which doesn’t seem to be intended!)

“our fast, focused, unit specs.”

I think this might be better as “our fast, focused unit specs,” without a comma between “focused” and “unit.” I don’t know the name of the grammatical rule for this, but “unit” functions differently than the other adjectives. It’s kind of part of the name. We aren’t saying we have specs that are fast, focused, and unit; we’re saying we have unit specs that are fast and focused. We wouldn’t say “our fast, unit specs”

I would say : and we won’t be explaining.
Note that #81135 page 50 is on page 42 for me, section Getting Started, second paragraph, second line : on.1 You don’t need to know …
I have reinstalled Adobe Acrobat Reader DC on my Mac to be sure it’s not a version problem. Same version 2015 as before :
Architecture: x86_64
Build: 15.23.20053.211670
AGM: 4.30.67
CoolType: 5.14.5
JP2K: 1.2.2.37658

HTH

Hi Myron,
before reporting an issue, I check if it does not already exist in the errata. I wanted to report for page 42, the previous erratum was on page 34, the next on page 50, hence I was about to add a new issue for page 42. It happens that my eye was catched by the first line of #81135 page 50, which was exactly the sentence for which I wanted to report a suggestion. That’s why I was in doubt about my version of Acrobat Reader and reinstalled it. As the page number didn’t change, I nevertheless added my suggestion for page 42 with a link to #81135, because I was reiterating an equivalent suggestion, but not for the same page.
If our page number is not the same as yours, you’ll have a hard time to find where to look in the book. I make the effort to copy-paste the section title, give the paragraph number, line number, and triple-check before submitting. If I don’t have the same page numbering and formatting as you, it may be wasted time.
So two questions :
- on which page for you is the sentence

“You don’t need to know anything about Bundler to follow along, but we
won’t be explaining it in depth.”

42, 50 or other, does it matter ?

- which context helps you the most ?

Thanks for your time.

I have a discrepancy with 04-acceptance-specs/04/expense_tracker/spec/acceptance/expense_tracker_api_spec.rb

When running with lines 28 - 32 :

post ‘/expenses’, JSON.generate(coffee)
expect(last_response.status).to eq(200)
puts “ last_response.body=#{last_response.body.inspect}”
parsed = JSON.parse(last_response.body)
expect(parsed).to include(‘expense_id’ => an_instance_of(Integer))

I have the following error :

$ bundle exec rspec

last_response.body=“”
F

Failures:

1) Expense Tracker API records submitted expenses
Failure/Error: parsed = JSON.parse(last_response.body)

JSON::ParserError:
A JSON text must at least contain two octets!
# ./spec/acceptance/expense_tracker_api_spec.rb:31:in `block (2 levels) in ’

Top of page.
The test is not passing, even using the book code, after copying my Gemfile into the expense_tracker folder :

$ pwd
……/Effective testing with RSpec 3/code/04-acceptance-specs/04/expense_tracker
$ bundle exec rspec
F

Failures:

1) Expense Tracker API records submitted expenses
Failure/Error: expect(parsed).to include(‘expense_id’ => an_instance_of(Integer))

expected {“expense_id” => 42} to include {“expense_id” => (an instance of Integer)}
Diff:
@@ –1,2 +1,2 @@
-“expense_id” => (an instance of Integer),
+“expense_id” => 42,

# ./spec/acceptance/expense_tracker_api_spec.rb:32:in `block (2 levels) in ’

I have followed the book for the installation, I think. Before I have created a special gemset ‘exptrack’ to isolate the gems installed for the book :

$ rvm current
ruby-2.3.3@exptrack
$ rvm gemdir
/Users/b/.rvm/gems/ruby-2.3.3@exptrack
$ which rspec
/Users/b/.rvm/gems/ruby-2.3.3@exptrack/bin/rspec
$ gem list

* LOCAL GEMS*

bigdecimal (default: 1.2.8)
bundler (1.14.4)
bundler-unload (1.0.2)
coderay (1.1.0)
did_you_mean (1.0.0)
diff-lcs (1.3)
executable-hooks (1.3.2)
gem-wrappers (1.2.7)
io-console (default: 0.4.5)
json (default: 1.8.3)
minitest (5.8.3)
net-telnet (0.1.1)
power_assert (0.2.6)
psych (default: 2.0.17)
rack (1.6.5)
rack-protection (1.5.3)
rack-test (0.6.3)
rake (10.4.2)
rdoc (default: 4.2.1)
rspec (3.6.0.beta2)
rspec-core (3.6.0.beta2)
rspec-expectations (3.6.0.beta2)
rspec-mocks (3.6.0.beta2)
rspec-support (3.6.0.beta2)
rubygems-bundler (1.4.4)
rvm (1.11.3.9)
sinatra (1.4.8)
test-unit (3.1.5)
tilt (2.0.6)
$

Same as #81150. I may have missed something in the installation. To make the example work, even using the book code freshly re-downloaded, I have to replace line 26 of file
…/code/04-acceptance-specs/05/expense_tracker/spec/acceptance/expense_tracker_api_spec.rb

## expect(parsed).to include(‘expense_id’ => an_instance_of(Integer))
by
expect(parsed).to include(‘expense_id’ => 42)

Bottom of page, using curl.
I am completely new to using Web services. I had the feeling that curl doesn’t work, because it immediately displays the prompt :

vmEC-Devl:expense_tracker b$ curl localhost:9292/expenses/2016-07-01
[]vmEC-Devl:expense_tracker b$

I hadn’t seen that the brackets [] are hidden before the prompt, that I’m used to ignore, looking only after the $.

Suggestion : a hint to look at the beginning of the line.

PS : not to mention that I had copied the line from the book, including the $. So I had errors like

$ $ curl localhost:9292/expenses/2016-07-01
-bash: $: command not found
Then
$ brew doctor …
$ brew install curl …
It didn’t work anyway. Googling for curl: command not found etc, etc, etc.
One hour lost before I realised my mistake :-(

Sentence after the second code snippet :
“When a spec fails, the printed backtrace can contain dozens of lines of framework code and obscure the application code you’re looking for.”

—> can contain … AND obscure the code
I stumble over AND, it sounds strange. Instead of AND I would say that/which if obscure is a verb, or something else is missing,

or

the printed backtrace, which can contain dozens of lines of framework code, obscureS the application code

You encourage to install Ruby 2.4 and give a bare footnote to ruby-lang.org. As I exclusively use homebrew and RVM, which are so wonderful, for my installations, I did this :

$ rvm install ruby
Already installed ruby-2.3.3.

believing it would install the latest. The answer made me think that 2.4 was not yet available with RVM. As I had just replaced 2.3.0 by 2.3.3 on February 2. 2017, I thought it was good enough and didn’t worried more about it.

Suggestion : I know there are tons of Linux and that you can’t make a chapter on installing Ruby, but explicitly give at least a few of the most used systems.

For Windows, Oneclick Installer if it still exists. I used it 12 years ago, very simple and comfortable. No need to compile.
For OS X (MRI) : $ rvm install 2.4

I’m going to start my explanation from scratch. Please delete the errata items #81160 page 59, #81158 page 60, #81156 page 61 and #81157 page 62.

I suppose that, as author of the book, you are interested to know how a lambda reader perceives and understands it. As I don’t know the content in advance, I have a different point of view. This is how I have perceived things step by step :

step 05-unit-specs/02/ on page 58 (always PDF printed page)

expense_tracker/spec/unit/app/api_spec.rb

has empty examples.

step 05-unit-specs/03/ at the bottom of page 61 is so :

it ‘responds with a 200 (OK)’ do
expense = { ‘some’ => ‘data’ }
➤ allow(ledger).to receive(:record)
➤ .with(expense)
➤ .and_return(RecordResult.new(true, 417, nil))
post ‘/expenses’, JSON.generate(expense)
expect(last_response.status).to eq(200)
end

1) My surprise is the three arrows. In all Pragmatic Bookshelf books I have read so far, arrows draw attention on new or modified lines of code. Here the whole do/end block is new. Following the practice, it should not be highlighted at all.

2) Then I read the first paragraph on page 62 :

“In the highlighted lines, we’ve specified the test double’s behavior: when the caller (the API class) invokes record, the double will return a new RecordResult instance indicating a successful posting.”

—> when the caller (the API class) invokes record : for the moment, I don’t understand what it means, so I read further. After the test output I see :

“It passes, because the API is already hard-wired to return a 200”

Then I still less understand the relationship between the ledger and the status. If 200 is hard-coded, why bother with that allow(ledger) stuff ?. So I comment it out, and the test passes as well.

step 05-unit-specs/04/ on page 64 “Implementing the API Behaviour”
expense_tracker/app/api.rb

The post code is changed and it has a side effect on my first example where the allow(ledger) lines are still commented out. As a code writer I would immediately create a new context for the second example. For you it has a pedagogical interest to have both examples with the three allow(ledger) lines, so that you can introduce refactoring and before hook on the next page.

My suggestion is as follows :

a) On page 61 bottom “Now, you’re ready to fill in the body of the first example:”
The second code snippet of the page
05-unit-specs/03/expense_tracker/spec/unit/app/api_spec.rb
should only contain (without arrows, because whole new code) :

it ‘responds with a 200 (OK)’ do
expense = { ‘some’ => ‘data’ }
post ‘/expenses’, JSON.generate(expense)
expect(last_response.status).to eq(200)
end

This example tests the Sinatra status, not the ledger receive.

b) Move the first paragraph on page 62 to page 63 after filling the second example in section “Moving On to the Next Spec”. The explanation will be closer to the modification of the post.

c) Hence the second paragraph “One other thing” should be “One thing”.

d) On page 64, “Moving On to the Next Spec” needs a little change :

Now that we know the app is returning the correct status code, let’s move on
to the next bit of behavior: returning the correct ledger status and expense ID.

e) Re-add a new first example changed from

it ‘responds with a 200 (OK)’ do

to

it ‘responds with success’ do
expense = { ‘some’ => ‘data’ }

allow(ledger).to receive(:record)
.with(expense)
.and_return(RecordResult.new(true, 417, nil))

post ‘/expenses’, JSON.generate(expense)

ledger_response = JSON.parse(last_response.body)
expect(ledger_response[‘success?’]).to be true
end

and change the last two lines of the second example to

ledger_response = JSON.parse(last_response.body)
expect(ledger_response).to include(‘expense_id’ => 417)

Now we have both examples failing instead of only the second one :
—————————-* begin output *—————
when the expense is successfully recorded
responds with success (FAILED - 1)
returns the expense id (FAILED - 2)
… (truncated)
Failures:

1) ExpenseTracker::API POST /expenses when the expense is successfully recorded responds with success
Failure/Error: expect(ledger_response[‘success?’]).to be true

expected true
got nil
# ./spec/unit/app/api_spec.rb:36:in `block (4 levels) in ’

2) ExpenseTracker::API POST /expenses when the expense is successfully recorded returns the expense id
Failure/Error: expect(ledger_response).to include(‘expense_id’ => 417)

expected {“expense_id” => 42} to include {“expense_id” => 417}
Diff:
@@ –1,2 +1,2 @@
-“expense_id” => 417,
+“expense_id” => 42,

# ./spec/unit/app/api_spec.rb:49:in `block (4 levels) in ’

Finished in 0.04566 seconds (files took 0.18554 seconds to load)
4 examples, 2 failures, 2 pending
—————————-* end output *—————

This is more “normal” than with “expect(last_response.status).to eq(200)” which has nothing to do with the ledger, making the first example always green, whatever the ledger is doing.

Well, it has been a good understanding exercise for me, printing plenty of traces, values, self, caller backtrace, ancestors, methods in ancestors. Feel free to ignore this post if it is too disturbing. I just try to help making a better book.

I have checked : [One-Click] RubyInstaller is still maintained :

https://rubyinstaller.org (hyperlinks are not allowed in errata, remove)

The only drawback is that it is still in 2.3.3.

Section Refactoring, paragraph after the code snippet :

“These now report “just the facts” of the expected behavior. When a POST request arrives, the response code should be 200 …"

I’m sorry to contradict, but we are not testing the server, we are testing the ledger, if I well read the cascade of example descriptions (underscores because spaces are removed when submitting) :

ExpenseTracker::API
__POST /expenses
__when the expense is successfully recorded <<< by the ledger ?!
__responds with a 200 (OK) <<< Sinatra
__returns the expense id <<< the ledger

The first example is independent of the ledger implementation and I prove it :

—- file spec/unit/app/api_spec_page_65.rb —-

puts ‘ spec 13:57’
require_relative ‘../../../../code/05-unit-specs/04/expense_tracker/app/api’
require ‘rack/test’

module ExpenseTracker
RSpec.describe API do
include Rack::Test::Methods
let(:ledger) { instance_double(‘ExpenseTracker::Ledger’) }
let(:app) { API.new(ledger: ledger) }

describe ‘Sinatra’ do
context ‘always’ do

before do
class XYZ
def expense_id
123456789
end
end

@xyz = XYZ.new
end

it ‘responds 200’ do
expense = { ‘some’ => ‘data’ }

allow(ledger).to receive(:record)
.with(expense)
.and_return( @xyz )

post ‘/expenses’, JSON.generate(expense)
expect(last_response.status).to eq(200)
end
end # context
end
end
end

$ bundle exec rspec spec/unit/app/api_spec_page_65.rb

spec 13:57

ExpenseTracker::API
__Sinatra
__always
__responds 200

Finished in 0.028 seconds (files took 0.17943 seconds to load)
1 example, 0 failures

The example it ‘responds with a 200 (OK)’ should go in a separate context testing the server.

There is an unnecessary short-circut/lazy-assignment in `initializer` for `@ingredients` in the example `Coffee` class:

```
def initializer
# ingredients ||= [] ingredients = []
end
```

“a flexible API that mirror’s Ruby’s raise method” - should be “mirrors”

The text says “This snippet shows off something we haven’t talked about before: getting access to your example’s properties at runtime. You can do so by having your
it block (or in this case, your specify block) take an argument.”

However, the code sample preceding this text does not use “specify”; it uses “it.”

On the spec type cheat sheet, both model and job tests say “Database transactions and model fixtures (available for all spec types, but most relevant here)”, at first it seemed like a mistake. When I read it under model specs I thought it meant “this is the ONE type of spec where transactions and fixtures are MOST relevant.” So I was surprised to see that under jobs too. If the intent is that these features are more relevant in these TWO types of specs than others, changing it to say “more relevant here” seems to avoid this misunderstanding.

be_a_new is defined in terms of record.new_record? But be_a_new_record is defined instead in terms of record.persisted? Is that actually the case in the implementation? It seems like the two should have identical newness checks, and the former would just have an additional type check. If this really is the implementation then it’s not clear why, but maybe this appendix isn’t the place to get into that. I guess a footnote could help if the answer is brief, or if it’s helpful for people to know.

Middle of the page :

>> expect(movie).to receive(:record_review).with(‘Good’)

I have restarted an IRB session, gave require ‘rspec/mocks/standalone’, then

> expect(movie).to receive(:record_review).with(‘Good’)

The result is :

NameError: undefined local variable or method `movie’ for main:Object

—> It seems that the definition of movie is missing, something like :

> movie = double(‘Jaws’)

even if I had kept the same IRD session since chapter 13.

Also missing `imdb’

>> allow(imdb).to receive(:rating_for).and_return(3) # default

Middle of the page after class BoxOffice :

The good news is that that the hash_including constraint works just as well with

—> twice “that”.

Top of page, typing in IRB :

> expect(client).to receive(:current_price).at_most(:twice).and_return(130.0)

NameError: undefined local variable or method `client’ for main:Object

> stock_ticker = StockTicker.new(client)

NameError: uninitialized constant StockTicker

—> I have found a file code/14-customizing-test-doubles/constraints.irbr where all the necessary commands are typed. It is just that they are not printed in the book.

Actually “client = instance_double(‘NasdaqClient’)”, IS printed on page 247, but without the green `>>` indicating it has to be typed.

As far as StockTicker is concerned, if I type

> require ‘./code/14-customizing-test-doubles/stock_ticker’

I have an error :

LoadError: cannot load such file — ./code/14-customizing-test-doubles/stock_ticker

When I started the IRB session, I used the terminal tab where the current directory was still

…/Effective testing with RSpec 3/expense_tracker

—> Suggestion : it should be noted on page 223, in the sentence

To use this mode, fire up IRB and require the following file:

to first `cd` to the parent directory of ‘code’. If I cd .., then “require ’./code/14-…” is OK, because “code” is installed in “Effective testing with RSpec 3”.

Twice “that” in section Stubbing a Constant, paragraph after the code snippet :

This pattern is useful enough that that RSpec provides a way to implement

—> is it the “that that” you are talking about in #81372 ?

First sentence after section title “Helper Methods” :

Sometimes, we get can get too clever for our own good …

—> we get can get ?!

Third paragraph in section “Logging Example Descriptions” :

First, open spec/support/db.rb and add the following lines to the end of it:
require ‘logger’
DB.loggers << Logger.new(‘log/sequel.log’)

—> Also saying to create a `log` directory under `expense_tracker` would avoid the following error :

$ bundle exec rspec spec/integration/app/ledger_spec.rb
An error occurred while loading ./spec/integration/app/ledger_spec.rb.
Failure/Error: DB.loggers << Logger.new(‘log/sequel.log’)

Errno::ENOENT:
No such file or directory @ rb_sysopen - log/sequel.log

First line :

However, as you spec suite grows and starts taking longer to complete

—> your instead of you ?

My eyes also stopped reading at the last sentence of the second paragraph :

Afterward, we’ll dig into how the formatter works.

—> expecting Afterwards (well Afterward is US English).

Title of the green info box :

Be Careful What You Load from spec_helper.rb

—> sounds like a With/About/Of is missing ==> Be Careful With What You Load

Second to last paragraph :

This example uses the Fuubar formatter, which is one of the more popular

—> most instead of more ? (which expects a than : for them enthusiasm is more important than talent / the most important event of my life)

“In this chapter, we’re going to show you that RSpec’s usefuless isn’t confined”

should be

“In this chapter, we’re going to show you that RSpec’s usefulness isn’t confined”

in chapter 2.

The ‘Place the following code just inside the first context block:’ seems to be wrong in my PDF - instead of:

before do
allow(ledger).to receive(:record)
.with(expense)
.and_return(RecordResult.new(true, 417, nil))
end

it should be:

let(:expense) { { ‘some’ => ‘data’ } }
before do
allow(ledger).to receive(:record).with(expense).and_return(RecordResult.new(true, 417, nil))
end

Thanks, enjoying the book so far!

The RSpec output in “Marking Work in Progress” includes yellow text on a white background, which is marginally readable in the PDF version of the book. In the ePub version, in Apple iBooks at least, the text is completely unreadable. Perhaps use a more contrasting colour?

The statement below mentions that there should be color. Maybe a note that the color will exist only if you “did” install the mentioned version in the book (3.6.0.beta2). I did not think the version would matter. I installed only using the command `````“gem install rspec”

Text from book:
Additionally, the output is in color. RSpec uses color to emphasize different parts of the output:

Looks like there was already syntax highlighting even prior to installing the coderay gem.

I think it would be beneficial if there will be an info box that explains what the “allow” RSpec syntax is doing.

Other RSpec syntax and terms were introduced/described. I think this would benefit from the same since it has an impact on the interaction with the API.

It looks like there is missing a “let” declaration similar to the one on page 68 for “expense”. The refactored tests on page 67 returns a “NameError” for expense.

In pdf page 105, the it block in the getting_the_words_right.rb is the following

expect(gadget.slices?).to be_true

But I think it should be

expect(gadget.slices?).to be_truthy

At the bottom of the page:
Add the following specs inside the RSpec.describe block in spec/integration/api_spec.rb

Fix: the path should be ‘spec/integration/app/ledger_spec.rb’

The downloaded file data_generator_spec.rb has incorrect method name(typo).

The line 105 of data_generator_spec.rb is the following

expect(users).to all_match_the_shape_of_user_record

But, it should be

expect(users).to all_match_the_shape_of_a_user_record

Typo in downloaded data_generator_spec.rb is found in the book, too.

expect(users).to all_match_the_shape_of_user_record

should be

expect(users).to all_match_the_shape_of_a_user_record

“we’d have to manually keep the two spec files in sync.” The “we” at the start of the sentence should be capitalized.

“Ruby’s JSON library can safely parse simple a record like this one into a Ruby
hash”

“simple” and “a” are in the the wrong order.

Should be

“Ruby’s JSON library can safely parse a simple record like this one into a Ruby
hash”

When running “rspec —profile 2” you display the result as “5 examples, 0 failures”. But on the previous page (19), we haven’t yet fixed the error for coffee with milk spec:
“Finished in 0.0102 seconds (files took 0.09104 seconds to load)
2 examples, 1 failure”.
Wouldn’t it be wiser to either fix the error by implementing the missing code or display the error when running with —profile option ?

The phrase “but you can also also add helper” contains double “also”.

… so you’d like to memoize (cache) the result should be

so you’d like to memorize (cache) the result.

I’m not positive this is a mistake, but I would have thought this should say ‘RSpec matchers…’ as opposed to what it currently says, “RSpec expectations…”

‘RSpec expectations perform the same check internally that Ruby’s case state- ment does: they call === on the object you pass in. That object can be any- thing—including another matcher.’

Text reads
“Ruby’s JSON library can safely parse simple a record like this into a Ruby hash:”

Should this be:
“Ruby’s JSON library can safely parse a simple record like this into a Ruby hash:”

difference is “simple a record” and “a simple record”

Code sample uses ‘RSpec.configure do |rspec|; rspec.alias_example_group…’ when it should match our code from previous chapters ‘RSpec.configure do |config|; config.alias_example_group…’

mid page “you can include Ruby modules into and RSpec context”
This could be made clearer by saying “into an RSpec context or describe block” as it is really being included in the latter in this example. If you meant to use context as English and not Ruby code then this mix up is unavoidable.
Great book so far. Thanks!

The second test uses the same date as the first, which does have entries. Maybe add a note in the text to remind the reader that the database is cleaned out between the two tests. That’s why the initial entries don’t show up in the second test.

In the very last page of the PDF, there is a “Contact Us” section with links, including some email addresses. When I click on any of the email addresses (in Preview on macOS 10.13.5), I get an error message in a new dialog box:

“There is no application set to open the URL support@pragprog.com.”

This sounds like the URL in the href behind those links is missing the “mailto:” protocol qualifier.

05-unit-specs/07/expense_tracker/app/api.rb

JSON.generate(​’error’​ => result.error_message) ——-> JSON.generate(​’error_message’​ => result.error_message)

The curl requests don’t work. They return “Sequel::DatabaseError: SQLite3::SQLException: no such table: expenses”.

TextMate ™ is another popular editor and will run xx_spec.rb files and give results. Also has shortcuts. Need to select RSpec in Preferences>Bundles and set the file type to RSpec to get all the goodies. macromates.com. I’ve been using TM for years.

May require adding the gem coderay to work.

Trying out the exercises and the first test wont work. Tried using the source code and this will not work either. I have updated the ledger class also:
context ‘when expenses exist on the given date’ do
before do
allow(ledger).to receive(:expenses_on)
.with(‘2017-06-12’)
.and_return([‘expense_1’, ‘expense_2’])
end

it ‘returns the expense records as JSON’ do
get ‘/expenses/2017-06-12’

expect(parse).to eq([‘expense_1’, ‘expense_2’])
end
it ‘responds with a 200 (OK)’
end

1. Maybe I’m missing something but when my code looks like the source it should surely work…

$ rspec -rtrail_map -rsupport/verify_doubled_constants

should be

$ rspec -rsupport/verify_doubled_constants

since we try to avoid expensive loading of the external library but still benefit from checking for missing constants.

2nd para “First, we run all the migration files in to make sure…”
This probably should be "First we run all the migration files in ‘db/migrations’ directory to make…