Historical errata for Rails 5 Test Prescriptions

“wring” should be “wrong” in “..behavior of the system when things go wring, and most of the things that..” on page 6 paragraph 6

Tests can be useful in documenting the expected behavior of the system when things go wring,

I suggest NOT fixing this typo — its perfect!

The code snippet contains:

basics/07/app/models/project.rb
def on_schedule?
(Time.zone.today + projected_days_remaining) <= due_date
end

and the paragraph following references that as (Date.today + projected_days_remaining)

The example at the top of this page seems to have a typo. It says:

it “can create doubles” do
twin = double(first_name: “Paul”, weight: 100)
expect(double.first_name).to eq(“Paul”)
end

Should the expect not be: expect(twin.first_name).to eq(“Paul”)

There is an extra “and” at the and of the first paragraph.

“…iteration of the loop has failed and and hard to run…”

“The first says that a brand-new tests is not complete”
should read
“The first says that a brand-new Task is not complete” (replacing tests with Task)

AND

“that it is than complete”
should read
“that is is then complete” (replacing than with then)

“when things go wring,” should likely be: “when things go wrong,”

States request specs don’t render views but I think this is incorrect. In a fresh Rails 5.1 app + RSpec 3.7 with unmodified config, given a matching route, controller, and view:

RSpec.describe ‘Home’, type: :request do
it ‘renders HTML’ do
get ‘/’
puts response.body # outputs layout.html.erb + matching view
assert_select ‘html’ # passes
end
end

Rightly or wrongly I use this to test view behavior where system specs would be overkill, and where I’ve moved away from view specs.

Controller specs however don’t render bodies by default (without an explicit call to render_views).

be_part_of_velocity doesn’t match code from block on page 34, which states be_a_part_of_velocity

When you run racks test -> (rails? rake?)

After scoping the order of project tasks, I had a few unrelated tests fail. I ended up needing to add inverse_of to the relationships to make it work.

> /app/models/project.rb
has_many :tasks, -> { order “project_order ASC” }, dependent: :destroy

became

> /app/models/project.rb
has_many :tasks, -> { order(project_order: :asc) }, dependent: :destroy, inverse_of: :project

> /app/models/task.rb
belongs_to :project, inverse_of: :tasks

The cucumber feature test is in the “features” directory not the “feature” directory. It should be “cucumber features/add_task.feature” instead of “cucumber feature/add_task.feature”.

Type in test name “uses the fake laoder to load a Project”. It should be “uses the fake loader to load a Project”.

The line require test_helper … as the test_helper file

should be

The line require “test_helper” … as the test_helper.rb file

In the first paragraph, the author writes “This test fails first on the creation of Task.new(size:2, completed:true)” when in-fact, using the code as it is written up to the that point, the test actually passes.

After reaching the section “Connecting the JavaScript to the Server Code”, I ran the rails server and the webpacker dev server and noticed that the “projects.js” was not working… The dom does not have a class “.task-table”. Also this book have many errors everywhere and it should not been on release since it is not ready to be sold. The tests passes even when the app is not working as intended, I though the TDD was a way to make your code work in a solid way but I realize after reading the 60% that this is false. Tests that passes with a broken app? Come on.

Going forward in the code examples I found that the code was missing on previous chapters, but included in later chapters, and that way I was able to make the web app works successfully. I also found that the swap_order_with method has an error, to reproduce it simply add 3 tasks on a project, then start the rails and webpack server then click “Up” on the second element on the list, you will see a backend exception undefined method project_order for nil:NilClass.

At this point of the book, I found that front-end has a critical error: the DOM task_#id was actually the project_order you can notice this on the project.js file, the functionloadFromData is creating new instances of Task and assigning the id as the project_order. This has to be a joke… Since the core of the app / tests are based on the ID the hole tests breaks when you put the correct code, which is the task ID.

If you run the tests at this point, typing everything in exactly, you get an error with the Project#total_size method.

Specifically, the error is: “nil can’t be coerced into Integer”.

This also happens with Project#remaining_size.

If I look at the Task object being passed in, it does have a size. For example:

Task:0x00… completed=true, size=2

So size is most definitely not nil.

I have double-checked the code as it is provided in the book and I have a line by line comparison showing no difference in code at all. And, again, you can see the object representation I’m getting above, so I definitely have @size and it definitely has a value. So I have to assume I’m not reading the error correctly.

Sizable is misspelled throughout this chapter which impacts the module name and filename. Which is the main issue. But most importantly, the code snippet on page 96 uses the correct spelling, which is inconsistent with the previous code. Here, “sizable” should be “sizeable” to match the other incorrect spellings.

(I’m curious about how the misspelling made it through the spell check process.)

At this point in the test, there is a method Project#total_size. But this section depends on a Project#size method, which the custom matcher uses. Running this code results in a NoMethodError. The test should guide readers into implementing a Project#size method or the custom matcher should be rewritten around the #total_size semantics.

was #{actual}
should be
was #{actual.size}

Otherwise the test failure message displays the object representation and not the meaningful actual value.

First bullet: “attributes_for” is incorrectly written as “attribute_for”.

Second paragraph:
“My preferred strategy is to not specify attributes”
should be:
“My preferred strategy is to not specify associations”

The state of the project_spec “estimates” section does not match the traits created in this chapter, and so applying those traits causes tests to fail. See page 113 (data/01/spec/models/project_spec.rb) for the starting state.

While the book indicates a subtle change (from 5 to 6 in the test) it should also indicate a change to the following test:

it “knows its projected days remaining” do
expect(project.projected_days_remaining).to eq(42)
end

(Was 35.)

When I ran bin/factory_bot.rb, I got a different notification for panic:

* panic - uninitialized constant Panic (NameError)
\tfrom /Users/aaron/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/factory_bot-4.8.2/lib/factory_bot.rb:69:in `lint’
\tfrom bin/factory_bot.rb:5:in `

The second code listing is both vague and includes a technical error. This:

twin = double(first_name: “Paul”, weight: 100)
twin = double
allow(twin).to receive(first_name).and_return(“Paul”)
allow(twin).to receive(weight).and_return(100)

Should be:

twin = double(first_name: “Paul”, weight: 100)

1. Equivalent to:
   twin = double
   allow(twin).to receive(:first_name).and_return(“Paul”)
   allow(twin).to receive(:weight).and_return(100)

Note the breaking up of the code with a comment, and the use of symbols as arguments to ‘receive’.

Code listing mocks/01/spec/controllers/projects_controller_spec.rb should end with one more expectation:

expect(workflow).to have_received(:create)

In order to be aligned with the third bullet point on page 143, which states, “That the controller calls create on the return value of CreatesProject.new.”

The backticks and italics are not necessary for the initial code snippet:

allow(project).to receive(:method).and_yield(“arg”)

it “makes 1… in an entry project”

Should be

it “makes 1… in an empty project”

On this page (167), the listing for integration/02/spec/models/task_spec.rb should only contain a single test, “can determine that a task is first or last.” The remaining tests are introduced on page 169. The extra tests are inconsistent with the statement following the code listing on page 168, “That’s more assertions than I would normally place in a single test.” In addition, the implementation that follows does not enable the reader to have the unit tests pass - as there are more tests than the implementation addresses.

Solution: all the tests in that listing on page 167 should be removed except for “can determine that a task is first or last.”

The controller implementation on this page, integration/02/app/controllers/task_controller.rb should omit:

- the before_action
- the methods up and down

As they are intended to be introduced on page 170, in a listing for the same controller.

Here is features_add_task.feature

should be:

Here is features/add_task.feature

In the cucumber pages, although Rappin states the version of cucumber and cucumber-rails used, it is important to note that cucumber has changed the default step definitions to use strings instead of regexes.

As such, all the code excerpts that include the classic default cucumber regexes is inconsistent with what the reader sees when working with cucumber in this chapter. For consistency, I suggest using strings rather than regexes to match the default cucumber output for pending step definitions.

The Scenario Outline on pages 178-179 embolden the word in, with no explanation about why. This should be of normal weight, so as to not mislead the reader.

In the code listing, the first tr within tbody is inconsistent:

<tr id="task_<%= task.project_order " data-task-id=<= task.id >>

Should be:

When you generated the Rails application you included Webpacker…

But we did not, nor does the author prompt us to way back in chapter 2 where we:

rails new .

Instead of:

rails new . —webpack

As such, this section should explicitly describe modifying the Gemfile:

gem ‘webpacker’

Before running ‘rails webpacker:install’.

Ok, this technical error is a major one.

As of page 171, one major omission is that, in chapter 8, the author does not guide the user through an important addition to CreatesProject#convert_string_to_tasks. What was:

def convert_string_to_tasks
task_string.split(“\
”).map do |task|
title, size_string = task.split(‘:’)
Task.new(title: title, size: size_as_integer(size_string))
end
end

Should be, as evidenced by the code download in js_integration/01:

def convert_string_to_tasks
task_string.split(“\
”).map.with_index do |one_task, index|
title, size_string = one_task.split(“:”)
Task.new(title: title,
size: size_as_integer(size_string), project_order: index + 1)
end
end

Without this, the DOM id’s of the task elements after creating a new project with initial tasks is “task_”. You can verify this in the code in integration/02. Run the server, add a project, view the source, and notice the incorrect DOM ids.

This should be incorporated somewhere in chapter 8 before the “Retrospective” section, and enhanced under test.

The last test description reads:

“handles asking for the bottom task to move up”

But should be:

“handles asking for the bottom task to move down”

If the reader has been following along with the text up until page 203, he is found abandoned in completing the app to match the author’s. One must then rely on the provided source code. The problem is that integrating js_jasmine/03 with the text has a few discrepancies, causing the TasksController up/down methods to return 404s due to the url being sent in the ajax request, which uses the task order as the PK id of the task id param to find on the server-side.

In other words, the app in js_jasmine/03 is actually broken. To see how:

1) Visit /projects/new and create a new project with two tasks a and b.
2) Visit /projects/2 and see the project, with the tasks in order: a, b.
3) Reorder the tasks using the button, and see that they are visually re-ordered: b, a.
4) Reload the page, and see that the order is unchanged: a, b.

First paragraph:
…a have_http_matcher
should be:
…a have_http_status matcher

In task_requests_spec.rb, the let statement is the first time a factory is used to create a task that has no project. This will fail, since the belongs_to relationship is required.

Looking back at the provided book code, the author added required: false to the Task class belongs_to declaration way back in integration/02. However, this is never mentioned in the text, and is actually never necessary until chapter 11 - where a Task is created independent of a project for the first time.

As such, the test raises an error due to the let statement, and the reader should add required: false to the Task class belongs_to declaration. The text should either suggest the change here; or back in chapter 6 (factories) as this is the context where developers will experience a similar error in their work with factories; or back in chapter 8, where the author makes the change to the Task class in the book’s code.

The task_requests_spec.rb on page 230 should only introduce the testing of the false case, as the text only refers to it, and asserts that the test would pass (but both tests do not). In addition, on the next page, 231, the author presents the second test, which is now redundant.

Suggestion: on page 230, remove the “sends email when task is completed” test from the code listing.

First paragraph after the code listing, last sentence:

Note that… completing the test here

Should be:

completing the task here.

Second paragraph:

back to the its source

Should be:

back to its source

Fifth paragraph, last sentence:

of the form render “projects/data_row, project: @project”

Should be:

render “projects/data_row”, project: @project

After implementing the use of the helper to pass the view test, the test fails due to a problem in Project#on_schedule? that raises an FloatDomainError: Infinity. The author fixes this in display/04/app/models/project.rb in the code download, but makes no mention of this in the text.

Readers should change the implementation of Project#on_schedule? to :

def on_schedule?
return false if projected_days_remaining.infinite?
return false if projected_days_remaining.nan?
(Time.zone.today + projected_days_remaining) <= due_date
end

Suggestion: Present the error in the text, including a unit test and the new implementation.

It would be cool to see just a little more in the Using Presenters section where the reader is guided to swap out the helper calls with the new ProjectPresenter, and see the tests pass. This would entail:

projects_controller.rb#index:
@projects = ProjectPresenter.from_project_list(Project.all)

project_presenter.rb#name_with_status:
Mark the string returned as htm_safe.

app/views/projects/index.html.erb:
Swap name_with_status(project) with project.name_with_status

spec/views/projects/index.html.erb_spec.rb:
Load ProjectPresenter objects for the view, eg:
@projects = ProjectPresenter.from_project_list([on_schedule, behind_schedule])

Thanks for a great book!

In the test_helper.rb code listing, the require statement:

require ‘mocha/mini_test’

is deprecated, and should be:

require ‘mocha/minitest’

In the code listing for test/models/project_test.rb, the description:

“a project with no tests is estimated”

Should be:

“a project with no tasks is estimated”

Similar to errata suggestion on page 242.

The require statement:

require ‘mocha/mini_test’

is deprecated, and should be:

require ‘mocha/minitest’

Last paragraph. asset_select -> assert_select

Fourth paragraph:

“And the test passes as is, which should be a little suspicious.”

This is a little misleading, because running the suite displays a failure. The text is pointing to one specific test rather vaguely, and the code listing on page 264 has both the positive and negative log in tests. The ambiguity continues into the next paragraph:

“… it means you’ve done only half the test… you haven’t done the ‘blocking miscreants’ part.”

But we indeed did both halves, per the code listing on page 264.

I suggest either breaking apart the code listing on 264, and putting the second test into the proper context on page 265; or removing paragraphs 4 and 5, as I quoted above.

Last paragraph:

“With that addition to the system tests…”

should be:

“With that addition to the system, controller and request tests…”

Because without signing the user in, the specs will still fail:

spec/controllers/projects_controller_spec.rb
spec/requests/task_requests_spec.rb
spec/system/add_task_spec.rb

The first code listing, implementing #index, seems to forget that the previous implementation used a ProjectPresenter. This newest listing should fit that, and be presented as:

def index
@projects = ProjectPresenter.from_project_list(current_user.visible_projects)
end

It is not clear to the reader why the new tests on this page are depicted in the new file spec/requests/task_requests.rb rather than the existing spec/requests/task_requests_spec.rb. Furthermore, as the file does not end in “_spec.rb” rspec does not run it as part of the suite.

There’s a slightly larger technical oversight here. The code listing for task_requests.rb is invalid. You can prove this by running the test explicitly with rspec. The author / technical reviewers may have overlooked this as the tests in this file are not run with the complete suite do the the filename.

The issue is that the controller is expecting params[:task][:project_id] but this test does not generate that request - the project_id is missing from the params hash it is posting. The line:

post(tasks_path, params: {task: {name: “New Task”, size: “3”}})

Should be:

post(tasks_path, params: {task: {name: “New Task”, size: “3”, project_id: project.id}})

In both occurrences of the code listing for task_requests.rb.

Lastly, these tests should just be added to the existing task_requests_spec.rb file.

The tests here in the listing for spec/requests/task_requests.rb do not need the :js annotation - they don’t rely at all on client-side javascript. They are request specs, and these tests do not rely on js.

Toward the end of the page, when describing the belongs_to declaration, the use of ‘require: false’ is incorrect. It should be ‘required’. Better yet, it should be ‘optional: true’, which is the new approach for Rails 5.

The has_many declaration at the end of the page is missing a colon after ‘dependent’. It should read:

has_many :tasks, dependent: :nullify

The listing for shows_twitter_avatar_spec.rb uses the term “gravatar” which is an avatar service, and not relevant here. Should just be “avatar” as this feature is only using twitter avatars, not Gravatar ones.

The test needs the :js annotation/option. Because in previous chapters the client now uses ajax to retrieve the tasks and append them to the dom. Otherwise the test fails because the dom element #task_1 does not exist. This test should be:

test “shows an avatar”, :js, :vcr do

The url for the twitter profile image is not correct. As of this writing, Rappin’s twitter avatar url is:

“…/profile_images/950537388518006785/Wusx_fRo_400x400.jpg”

The code listing at the bottom of the page has an incorrect require:

require_relative “../active_record_test_helper”

Should be:

require_relative “../active_record_spec_helper”

As the next code listing presents the contents of the file active_record_spec_helper.rb.

The code listing at the bottom of the page is for test/models/project_test.rb but should be for spec/models/project_spec.rb.

When making the same changes as the author, and running the tests in project_spec.rb, an error is raised due to not including the Sizeable module and the shared examples in spec/shared/sizeable_group.rb.

States “The use of instance_double to create the test double…”, code block uses instance_spy.

Just after defining “class Task”, the next paragraph includes:
> also clear up the following failure, that project.done? doesn’t exist.

The #done? method already exists, defined in class Project on page 23. Perhaps the phrase meant to be something like “doesn’t change” or “doesn’t reflect the done state of the project”.

I’m reading via Safari do I don’t have a page number to provide, sorry.

In the section “Where to start” it lists some matchers, then says:

“Any of these matchers except raise_error can be negated by using not_to instead of using to.”

But raise_error can be negated, e.g.

expect { foo }.not_to raise_error

In the second “The Second Test”, it says “this example will fail since the two let blocks are never invoked”. But even if they were invoked using “let!”, the test would still fail because it’s use ‘new’ rather than ‘create’.

I’m reading via Safari do I don’t have a page number to provide, sorry.

> My preferred strategy is to not specify attributes in factories at all. If I need
> associated objects in a specific test, I explicitly add them to the test at the
> point they’re needed.

It should probably read is to not specify associations in factories at all

You also might see the use of dependency injection,
where the behavior of CreatesProject creating an instance of Project would be set
as a variable at runtime—usually something like def initialize(initialize(name: “”,
task_string: “”, class_to_create: Project). Allowing the class to be specified dynamically
allows the use of a class double or fake class in testing.

Double initialize

The second test should read
```
it “can not add a task to a project the user cannot see”, :js do
```
negation in the second part is missing.

attribute_for should be attributes_for

Currently this:

````
it “doesn’t allow creation of a task without a size” do
creator = CreatesProject.new(name: “Test”, task_string: “size:no_size”) creator.create
expect(creator.project.tasks.map(&:title)).to eq([“size”])
end
```
and I think it should be something like this

`
it “doesn’t allow creation of a task without a size” do
creator = CreatesProject.new(name: “Test”, task_string: “size:3\
no_size:no_size”) creator.create
expect(creator.project.tasks.map(&:title)).to eq([“size”])
end
`

Last page of the preface xvi, in the “Online Resources” section, the title of the book is misspelled. The typo is ’The Pragmatic Bookhself"

You have two specs here. The first says that a brand-new tests is not complete.
The second creates a different test object, marks it as complete, and expects
that it is than complete.

I think it should say brand-new tasks instead of tests. Same thing with creates a different test object, probably you mean a task object instead (not sure here, maybe you really meant a test object on this second occurence) . And finally a small typo at the end of the paragraph: then instead of than.(that it is then complete).