Historical errata for Rails 4 Test Prescriptions

task.complete! should be mark_completed

one complete test and at least one incomplete test.

.. should be
one complete task and at least one incomplete task.

Need to change POINT_RANGE to VALID_POINT_RANGE:

VALID_POINT_RANGE = 1 .. 5
validates :size, inclusion: {in: POINT_RANGE}

There is a method name mismatch between the test and the model.

In the test (project_test.rb) you call task.complete! but you define #mark_completed in the Task model.

The test don’t pass due to the undefined method #complete!

After the block of code.
This is wrong:
I’ve set up a test where a project has two complete
tasks and one incomplete task,

Correct is:
I’ve set up a test where a project has one complete task and two incomplete tasks,

In the penultimate paragraph you reference two times a #complete! method. The correct name of the method is #mark_completed.

Line 14 & 16 call #due_date from the Project class. This method don’t exist and is not created in basics/06/gatherer/app/models/project.rb.

An attr_accessor :due_date must be added.

“As it happens, the hallmark of easy to change code code is small methods that do one thing, are loosely coupled, and have minimal side effects.”

Duplication of word “code”.

In the test description on line 4:
wrong:
test “a user can add a a project and give it tasks” do
correct:
test “a user can add a new project and give it tasks” do

I believe the first paragraph:

“Given: What data does the test need? This test needs a project, at least one complete test and at least one incomplete test.”

should read:

“Given: What data does the test need? This test needs a project, at least one complete task and at least one incomplete task.”

“I’ve set up a test where a project has two complete tasks and one incomplete task”

should read:

“I’ve set up a test where a project has one complete task and two incomplete tasks”

In basics/04/gatherer/app/models/task.rb, class Task is missing:

attr_accessor :completed

Must should be “Most”

“Must of those attempts eventually wind up in a tangle of special case logic because each controller is actually going to eventually need to have different features.”

End of sentence missing. Sentence:

“So if we go off and redesign this page using more modern markup, as long as the size element is subordinate to the project element.”

should maybe read:

“So if we go off and redesign this page using more modern markup, as long as the size element is subordinate to the project element, the test will pass.”

“then clicking on a button labeled Submit”. Actually in the test code on page 37, the button is labeled “Create Project”

Last word on the page: “mange”, should be “manage”.

self.project = Project.new(name: name)
should probably be
self.project = Project.new(name: @name)

actual: “Which then passes with a by adding …”

expected (for example): “Which then passes by adding …”

“I can’t think of a an easy …” should be

“I can’t think of an easy …”

“For reasons that will be clear in a moment, we’ll starting …”
should be
“… we’ll be starting” or (?)
“… we’ll start”

“I don’t think we need to walk though …”
should be
“… walk through …”

“The resulting Test class looks like this:”
should be
“The resulting Task class looks like this:”

“The algebraic version clearer …”
should be
“The algebraic version is clearer …”

The closing parenthesis for the remark starting “(although one reviewer did suggest turning …” is missing.

I’m on chapter 3 of the book. I added the capybara gem to my solution, but when I run the first integration test, instead of getting the error:

AddProjectTest#test_a_user_can_add_a_a_project_and_give_it_tasks:
NameError: undefined local variable or method `new_project_path’ for
Chapter 3. Test-Driven Rails • 38
Prepared exclusively for Anthony Candaele report erratum • discuss#
test/integration/add_project_test.rb:5:in `block in ’

I getting the error:NameError: uninitialized constant Capybara

I guess some further Capybara configuration needs to be done?

gem install ‘factory_girl_rails’

Must be:

gem ‘factory_girl_rails’

due_date { Date.today - rand(50)

Must be:

due_date { Date.today - rand(50)}

media.pragprog.com/titles/nrtest2/code/basics/02/gatherer/test/models/task_test.rb
third line says “task.mark_completed”

In the book it says:
task.complete!

This results in an error if you run rake task:all at the end of the chapter:
TaskTest#test_a_completed_task_is_complete:
NoMethodError: undefined method `complete!’ for #<Task:0x007fcf961e4430 completed=nil, size=nil>
test/models/task_test.rb:8:in `block in ’

PDF page number may be inaccurate due to the fact I’m reading it in iBooks and depending on the screen size it gives a different page number. But it is in in the “The Second Test” chapter starting on page 46. Only a few pages in.

location:
test_first/01/gatherer/test/integration/add_project_test.rb

Line 4
test “a user can add a a project and give it tasks”

Should be
test “a user can add a project and give it tasks”

Issue:
“a” character is repeated twice

Another one is on the same page where it says:
“This section starts on line 5 and ends on line line 8”

Should be:
“This section starts on line 5 and ends on line 8”

Issue:
“line” word is repeated twice.

Page numbers do not match up since I’m using iBooks and it gives a different page number based on how big or small I make the book.

‘and’ is written twice:
While the Rails framework and third party testing tools allow us to interact with controller actions and and

In section “What’s a Spec?” there appears to be a couple of words missing.

• “The RSpec docs and code refer to the elements of RSpec as .” (Assume missing word is ‘expectations’?)
• “The term I hear most often is simply , as in: ” (Assume missing words is ‘spec’)

Missing end quote in code example:

pending "not implemented yet

* Text reads: “… Rspec looks, at first glance, different that typical Ruby…”
* Assume it should read: “… Rspec looks, at first glance, different than typical Ruby…”

missing end quote in code sample
* Reads: render “projects/data_row, project: @project
* Shoud read: render ”projects/data_row", project: project

their/there grammar error:

Reads: “… and if their isn’t much logic …”
Should read: “… and if there isn’t much logic …”

In section “What’s a Spec?” there appears to be a couple of words missing.

• “The RSpec docs and code refer to the elements of RSpec as .” (Assume missing word is ‘examples’?)
• “The term I hear most often is simply , as in: ” (Assume missing words is ‘spec’)

Correction to issue #77087 (s/expectations/examples)

Should the sentence that reads “An entire suite of unit tests is like a house that’s all frame - overbuilt”, read “An entire suite of integration tests …” or even better, “An entire suite of integration tests acting as unit tests …”? On the previous page the author made the analogy of integration tests being the frame of a house, and the point of this paragraph seems to be warning against over using integration tests where unit tests would be more appropriate.

Sentence containing “… that I’ve been ignoring up to know … ” should probably read “… that I’ve been ignoring up to now …”

Shouldn’t sentence that reads “If you want an exact match rather than a substring match, then pass the option exact: false to any Capybara method that uses a locator.” be “If you want an exact match rather than a substring match, then pass the option exact: true to any Capybara method that uses a locator.”

Walking through the steps of the outside-in diagram the author states: “In a reasonably mature Rails application, the first few steps will often already pass.” This seems to contradict the outside-in, test-first principles, which if followed would mean that the integration tests would be written before the code.

Author states: “… that doesn’t need a test, as such, because it’s really part of the framework.” This is a great point that probably deserves to be emphasized more. If you’re writing tests just to validate that the framework is doing its job, you’re probably wasting your time, and duplicating tests that exist in the Rails source code.

Author states: “[Cucumber] allows me the option to describe the intended behavior of the system without using the code part of my brain at all…” — This is an excellent point that deserves emphasis, especially how it relates to the outside-in BDD process.

The when/and/then/and/when/then/and chain feels like it’s lumping too many things together and ought to be broken into multiple scenarios.

When describing the cuke keywords (‘Given’, ‘When’, ‘Then’, …), the author mentions ‘And’ and ‘But’, but doesn’t explain what they do. For those unfamiliar with Cucumber this might be confusing.

The choice not to use Active Record models here seems odd. Yes, not all Rails model objects use Active Record, but that’s the norm and seems like it should be the default place to start. It’s leading to some very un-Rails behavior in the code like using accessors and Arrays, rather than the AR associations that one would normally use to link models. The author does make note of this, and provides reasons for this choice, but it still feels wrong and distracting.

Perhaps it’s just left over emotional scaring from my Java days, but rather than leave the value of @completed nil, I would explicitly set it to false when absent from the options passed to the initializer:

@completed = options[:completed] || false

The author states we “… use the setup method, which is part of ActiveSupport …”

The #setup method is part of Minitest::Test itself, not ActiveSupport, right? (I double checked the source on Github to make sure.)

Perhaps the author was referring to additional functionality that Rails adds to #setup, but this sentence as it stands makes it sound like standard Minitest lacks the method entirely, which is not the case.

Wondering if there was a reason the author chose to use a one line if-then-else clause instead of the ternary operator, which seems like more idiomatic ruby to me.

Current:

if counts_toward_velocity? then size else 0

Suggested

counts_toward_velocity? ? size : 0

Regarding the text area for tasks, I’m wondering why this isn’t split up into separate fields for the task data, rather than having to do all this “faking” and parsing.

I like the SWIFT mnemonic. Surprised the authro didn’t reinforce it with more callbacks throughout out the rest of book.

second sentence, extra space, says “The tas k is”, should be “The task is”

Awkward sentence near the top of the page: “This is a key part of design happens, so don’t skip this.”

The paragraph about “blank page problems” in the middle of the page could be stronger. Particularly, explain what you mean by “and so on, and so on.” This is probably very difficult for a novice to understand.

You say “If you run the tests now, they should still all pass (except…” but the tests fail because they haven’t built a relationship between the project and tasks. The task project_ids are nil.

I cannot find a way to delete my previous incorrect report for this page. Please accept my apology for wrongly suggesting that the tests would not pass. My mistake.

“with no test to be done” should presumably be “with no task to be done” (the same text appears in the reports of the runs, of course).

‘specifyin’ should be ‘specifying’

Missing word: ‘The RSpec docs and code refer to the elements of RSpec as .’. Refer to them as what?

“Usually these files will just contain these epics” - presumably “epics” should be “specs”.

In the code ‘expect(actual).to match([an_object_eq_to(5), an_object_eq_to(7)’, ‘])’ is missing from the end.

The link to the rspec matchers documentation is wrong: rubydoc.info/github/rspec/rspec-expectations/RSpec/Matchers goes to “Oops, We Couldn’t Find That GitHub Project”

In ‘Testing for Failure’ the production code is written first, then the test that would pass on the first run. Should we not write the test first, see it fail first, then write the validation into the model?

Update to my suggestion oh I guess the failing test is the one about what the controller does based on the validation, still i would hold off on writing the production code without a failing test. the book says that a failing test is the only reason to make changes to the production code

The kind of tests written in a TDD process are is not a substitute
[extra word “are is”]

If you are not familiar with Rails, Agile Web Development
with Rails [RTH11] is still the gold standard for getting started.

[Since your book uses Rails 4, shouldn’t this be a reference to “Agile Web Development with Rails 4” (note the “4” in the title of the book) — by Sam Ruby (sole author), published 2013?]

Sometimes, rspec and rspec rails are updated separately
[shouldn’t that be “rspec and rspec-rails” with a hyphen?]

it “considers a project with no test to be done” do
[shouldn’t that be “a project with no tasks” (“tasks” not “test”)?]

Figure 1—RSpec Matcher Execution
first line: expect(project.done?).to be_truthy [the code has "project" not "project" — remove the “@” to be consistent?]

6th paragraph:
Creating three objects to test sort behavior (para 6), change word ‘excepted’ to ‘expected’

“Rollback or delete the fixtures as described earlier The result of each example”
[missing period]

“and if we run things, we fail pretty quickly Here’s the slightly edited”
[missing period]

“There’s also the teaching way, which somewhere in-between, and”
[missing word “which is somewhere”]

(first line of basics_rspec/02/gatherer/spec/models/project_spec.rb)
it “knows that a project with an incomplete test is not done” do
[shouldn’t that be “with an incomplete task is not done” (not “test”)?]

(code basics_rspec/05/gatherer/app/models/project.rb)
On this one you could put the sentinels around total_size and remaining_size, since the other methods haven’t changed. (I don’t know how your publishing markup system works, but in the other code examples there is a single ‘#’ above and below the code to be excerpted.)

Task#counts_toward_velocity
[should be Task#part_of_velocity? (with question mark)]

Should Task#part_of_velocity? really be part of the exposed interface for Task? The Project class doesn’t use it; it could be a private method of Task. The specs in basics_rspec/07/gatherer/spec/models/task_spec.rb would be simpler if they just checked that the Task#points_toward_velocity matched the expected value, since that’s all the Project class does.

an entire book by itself.(Specifically, this one
[add space after “itself.” before parenthesis]

#anyting
[should be “anything”]

“breaking it out into it’s own method that parses a single string”
[remove the apostrophe: “its own method”]

“Each individual test case is now it’s own describe.”
[remove apostrophe: “its own describe”]

“Three classic causes of repeatability problems are […]. In both cases,”
[the latter should be “In all three cases”]

“Sometimes called Heisnebugs, Heisnspecs,”
[not sure if those are ironic/humorous typos, or real ones. ;-) ]

“a separate layer of code, with it’s own responsibilities”
[remove apostrophe: “its own”]

validates :size, numericality: {less_than: 5}
[since you allow 1..5, this should be “less_than_or_equal_to: 5” — two places on this page]

“For example, when we created a new project we asserted that the project existed, and also asserted that it had a specific relationship with newly created tests.”
[last work in sentence should be “tasks”]

“Normally, custom matchers are placed in the spec/support folder is automatically imported when RSpec starts.”
[missing word(s) — maybe “the spec/support folder which is automatically”?]

In the sentence, “Similarly, if the predicate method starts with has, RSpec allows your matcher to start with have for readability so your tests don’t look like they have been written by LOLCats…”, “have” should be printed in the same typeface as “has”.

“allowing the stub to be declared the the
Given section”

“the” should be “in”?

A test completed in the last three weeks counts toward velocity, which implies two negative cases:
an incomplete test, and a test that was completed longer ago.

should be:

A task completed in the last three weeks counts toward velocity, which implies two negative cases:
an incomplete task, and a task that was completed longer ago

Shouldn’t it better if the description:

it “does not count a long ago task toward velocity” do

is

it “does not count a task completed long time ago towards velocity”

By default in rails_helper.rb I had this line hashed:

#Dir[Rails.root.join(“spec/support//*.rb”)].each { |f| require f }

when I add to task_spec.rb this line:

it_should_behave_like “sizeable”

I had:

No tests were found

Adding information about potential need to activate scanning spec/support directory can help sometimes.

Regard
Arkadiusz

In test_first_rspec/05/gatherer/app/views/projects/index.html.erb there is a , in: <tr class=“project-row”, id=“<%= dom_id(project) %>”> . This in not a valid HTML in result.

Instead of changing the project model, wouldn’t it be better to run the tests and add functionality as and when needed?
For example after generating the resources for the project and task, when running the tests, the error is: ‘The action new could not be found’.

Shouldn’t the belongs_to be added to the task model?

it “handles a multiple tasks” do

should be

it “handles multiple tasks” do

In the new view test using the have_selector there are two assertions that we test against hardcoded values for the title and the size. Since we have the instance variable @project, would it be better to test against that?

So wouldn’t it be better to replace:

expect(page).to have_selector(“#project#{@project.id} .name“, text: ‘Project Runway’)
expect(page).to have_selector(”#project#{@project.id} .total-size”, text: ‘8’)

with

expect(page).to have_selector(“#project_#{@project.id} .name”, text: ’project.name) expect(page).to have_selector("#project_#{project.id} .total-size", text: @project.total_size)

First you unit test the steam class to verify that the class works as expected.

should be

First you unit test the stream class to verify that the class works as expected.

That said, when you are writing tests are actually ifferent in that they cover, …

should be

That said, when you are writing tests that are actually different in that they cover, ..

It’s a little contrived, but work with me.

should be:

It’s a little contrived, but works with me.

it knows a one point story is small

should be

it knows an one point story is small

According to the ‘Conventions’ documentation of RSpec, when having a lot of shared exampels, custom matchers is better to include the individual files needed instead of loading all the files from the spec/support directory.
So in the example provided, since the spec directory is already included to the LOAD_PATH, you can use the following on the top of your task_spec (and prjoject_spec):

require ‘support/size_group’

Since we use a shared example, but there is only an example how to use it for the tasks, shouldn’t it better to provide an example of how can it be used from the projects too?

Hi,
I had an error in mocks/01/gatherer/spec/models/project_spec.rb
at line 118:
RSpec::Mocks::MockExpectationError: #<Project id: nil, name: nil, due_date: nil, created_at: nil, updated_at: nil> does not implement: user_count
./spec/models/project_spec.rb:118:in `block (2 levels) in <top (required)>’

And the end of each individual test, the transaction is rolled
back, restoring the initial state very quickly.

should be:

At the end of each individual test, the transaction is rolled back, restoring the initial state very quickly.

Older ruby syntax used:

Project.new(:name => “Project Greenlight”)

should be:

Project.new(name: ‘Project Greenlight’)

Older ruby syntax used:

Project.new(:name => “Project Greenlight”)

should be:

Project.new(name: ‘Project Greenlight’)

Older ruby syntax used:

Project.new(:name => “Project Greenlight”)

should be:

Project.new(name: ‘Project Greenlight’)

Older Ruby syntax used:

:project => {:name => ‘Project Runway’}

should be:

project: {name: ‘Project Runway’}

Adding

If the method in question is belongs to a third-party framework…

should be

If the method in question belongs to a third party framework…

“If you put your data in in …”

in the source code exemple: eq(“book_to_write”). I do not think it is right

“go go through”

in the source code: test_first_rspec/04/gatherer/spec/models/project_spec.rb
you have an interpreter error because projectproc does not exit.
It should be renamed project.

in source code display/05/…
rake db:mirate does not work because some old migration are also part of the migrate folder.
You need to delete the wrong migration files.

sorry: eq(“book_to_write”) is actually right

Missing ‘replace’ word.

—with a little bit more work, we could require rails_helper at the top of the file with require spec_helper.

should be:

—with a little bit more work, we could replace require rails_helper at the top of the file with require spec_helper.

Since we are using rspec for the tests the generated files from the rails g mailer TaskMailer should be different. So:

invoke test_unit
create test/mailers/task_mailer_test.rb
create test/mailers/previews/task_mailer_preview.rb

should be:

invoke rspec
create spec/mailers/task_mailer_spec.rb

For:

test ‘it finds completed tasks’ do
Task.delete_all
complete = Task.create(completed_at: 1.day.ago, title: ‘Completed’)
incomplete = Task.create(completed_at: nil, title: ‘Not Completed’)
assert_equal([complete], Task.complete.to_a)
end

I have error:

Minitest::UnexpectedError: NoMethodError: undefined method `complete’ for #
test/mailers/task_test.rb:44:in `block in ’
test/mailers/task_test.rb:44:in `block in ’

Solution is to check:
…titles/nrtest2/code/minitest/01/gatherer/app/models/task.rb

Where is not mentioned before method:

def self.complete
where([“completed_at < ?”, Time.current])
end

Regards

Is the TEST in the following needed?

rake test TEST=test/models/project_test.rb

test can also be run with:

rake test test/models/task_test.rb

it’s also task not project

the test is for the task and not the project as described in the text. So

a Project instance …

should be:

a Task instance …

and

the method call project.done?

should be

the method call task.complete?

Shouldn’t the following two lines be added to the top of the test file?

require ‘test_helper’

class ProjectsControllerTest < ActionController::TestCase

In the fourth bullet point on the page, the sentence “Rollback or delete the fixtures as described earlier” is missing a period at the end.

Add ‘$ bundle install’ to the listing to clearly show any commands the reader is expected to execute at the command line:

$ bundle install
$ rails generate rspec:install

We are in a middle of a process for Spec version. We have: test/fixtures/tasks.yml and should be: spec/fixtures/
tasks.yml

On the Minitest and Routing section the tests with assert_routing that includes the method in the path parameter fail with SyntaxError messages.

It seems that to make it work you have to pass the paramaters enclosed in brackets as in:

assert_routing ({ path: ‘/projects’, method: ‘post’ }), ({ controller: ‘projects’, action: ‘create’ })

The following two lines should be added on top of the project_test.rb file:

require ‘test_helper’

class ProjectTest < ActiveSupport::TestCase

Older ruby syntax used:

:name => “Project Greenlight”

instead of:

name: “Project Greenlight”

against an_object_eq_to(5) and an_object_eq_to(5), which are aliases to eq(5) and eq(7).

should read

against an_object_eq_to(5) and an_object_eq_to(7), which are aliases to eq(5) and eq(7).

second ‘5’ should be a ‘7’

in our original project_test.rb file

should be

in our original project_spec.rb file

In the source code exemple environment/02/gatherer I have a test failing.

To solve the problem you need to rename a variable in product.rb
def add_users(users2)
users << users2
end
So it knows that users is actually the attribute of the class and not the parameter

The second test lines 20-23 it should not be in the user_and_role_spec.rb file at this page as the test with it does not pass as described in the text.
As described in page 213 should be added later on.

Maybe it would be a good idea to point out that the order in config/routes.rb is important.

So if the root path is before the projects path the test for the /projects will fail.
The root path added should be last in the file.

As with our last pair of security tests, the test that assumes no blocking behavior passes, while the blocking test does not.

Both tests fail as no roles behaviour is established yet.

In integration/02/gatherer/app/models/task.rb we have:

def epic?
size >= 5
end

def small?
size <= 1
end

#
def epic?
size >= 5
end

def small?
size <= 1
end
#

In my situation changes were needed after the modification in the controller by creating the user again:

it “allows a user who is part of a project can see that project” do
user = User.create(email: “test2@example.com”, password: “password”)
log_in_as(user)
project.roles.create(user: user)
visit(project_path(project))
expect(current_path).to eq(project_path(project))
end

And I have in user_and_role_spec.rb this line:

let(:user) { User.create(email: “test@example.com”, password: “password”) }

But project.roles.create(user: user) is not working before my change somehow.

In security/01a/gatherer/spec/features/add_project_spec.rb there is a missing line. Should be:

before(:example) do
projects(:bluebook).roles.create(user: users(:user))
login_as users(:user)
end

There is better method to solve problem I showed yesterday. I make this change:

let(:user) { User.create(email: “test2@example.com”, password: “password”) }

I found this by experiment and having this kind of error:
ActiveRecord::RecordInvalid: Validation failed: Email has already been taken

with email: “test@example.com”

Now all works in my case.

There is no actual content related to JavaScript Fiddle in the “JavaScript Fiddle” section. It’s not referenced, there’s not links to external sources, no discussion of what it is or why you’d use it, nothing. Maybe consider adding at least a few lines giving the reader some idea of why it was brought up?

The sentence “But it’s no because none of the attributes are permitted.” should most likely be “But it’s not because none of the attributes are permitted.”

There seems to be 2 different bullet point lists which are not displaying as lists, but as paragraphs with sentences that are prefixed with an asterix.

One is after the sentence “We also introduce two characters to the story for design and testing purposes:”

The other is after the sentence “There are several kinds of tests that relate different combinations of these
objects:”

Shouldn’t the test on the last line of the controller be something like?

expect([project]).to eq(user.visible_projects)

Note: the page number entered is the location in the Kindle .mobi file, since there are no page numbers.

In the section “Our First Date”, in the file:

basics_rspec/07/gatherer/app/models/task.rb

the functions shown below should have “@completed_at” instead of “completed_at”. As the code is in the book, the tests in task_spec.rb fail even though the book indicates that they should now be passing. Using the instance variable in the code below allows the tests to pass as expected.

def complete?
completed_at.present?
end

def part_of_velocity?
return false unless complete?
completed_at > 3.weeks.ago
end

Given…
project show page when we display the list of tests.

should be:

Given…
project show page when we display the list of tasks.

The link to github.com/drapergem/draper> should be pointing to github.com/drapergem/draper

allow(AvatarAdapter).to receive(:new).with(user).and_return(fake_adapter) should be allow(AvatarAdapter).to receive(:new).with(user.email).and_return(fake_adapter)

In the test “doesn’t allow creation of a task without a size” the task_string has wrong formatting.

It is “size:no_size” but i think it should be more like “size:1\
no_size”

“Starting on line 5 and ending on line 8” should be “…ending on line 9”. Line 9 has the Capybara method ‘visit’.

rails generate migration add_public_fields instead of rake generate migration add_public_fields

In second block of code (visible_projects method), there’s an extra ‘end’ which is not needed.

Last paragraph seems to suppose to be a bullet point list, but is shown as block of text, which is harder to read.

Link at the bottom of the page doesn’t work.

In Chapter 5. Testing Models • 90

“The definition starts with a call to RSpec::Matchers.define, pssing it the name of the matcher and a block.”

pssing should be passing

Chapter 11: Testing for Security
Last page of the “Restricting Access” subchapter

‘We are all green’. I had three failing specs.
I also need to mention that I haven’t created the test subdir, and I don’t have mocha in my gems. I was following just the rspec part.

Fail 1:

2) ProjectsController GET show does not allow a user who is not part of the project to see the project
Failure/Error: controller.current_user.stubs(can_view?: false)
NoMethodError:
undefined method `stubs’ for #

Actions to correct:

- Change
controller.current_user.stubs(can_view?: true)
allow(controller.current_user).to receive(:can_view?).and_return(true)

Fail 2:

1) adding a new task can add and reorder a task
Failure/Error: fill_in “Task”, with: “Find UFOs”
Capybara::ElementNotFound:
Unable to find field “Task”

rspec ./spec/features/add_task_spec.rb:20 # adding a new task can add and reorder a task

Action to correct:
Create spec/fixtures/roles.yml

1. roles.yml
   role:
   user: user
   project: bluebook

The handling of down clicks of tasks are missing.

In projects.js:

nextTask: function(task_row) {
result = task_row.next();
if(result.length > 0) {
return result;
} else {
return null;
}
},
downClickOn: function(anchor_element) {
row = Project.taskFromAnchor(anchor_element);
nextRow = Project.nextTask(row);
if(nextRow == null) { return };
Project.swapRows(row, nextRow);
}

$(document).on(“click”, “.down”, function(event) {
event.preventDefault();
Project.downClickOn($(this));
});

“We than can make…” should be “We then can make”

I was confused when I saw

‘describe “adding projects” do’

because we had used the newer rspec describe style earlier:

‘RSpec.describe Project do’

is there a reason for using one over the other in these cases? One is a model test, and the other is a feature test…

Maybe add a note that they can be used interchangeably and the reason for switching style here.

After converting the models from plain old ruby objects to ActiveRecord models, I get the following errors when running the specs that are not mentioned:

2) Project initialization marks a project done if its task are done
Failure/Error: expect(project).to be_done
expected `#<Project id: nil, name: nil, due_date: nil, created_at: nil, updated_at: nil>.done?` to return true, got false
# ./spec/models/project_spec.rb:30:in `block (3 levels) in <top (required)>’

3) Task can distinguish a complete task
Failure/Error: expect(task).to be_complete
expected `#<Task id: nil, project_id: nil, title: nil, size: nil, completed_at: nil, created_at: nil, updated_at: nil>.complete?` to return true, got false
# ./spec/models/task_spec.rb:8:in `block (2 levels) in <top (required)>’

4) Task velocity counts a recently completed task toward velocity
Failure/Error: expect(task).to be_part_of_velocity
expected `#<Task id: nil, project_id: nil, title: nil, size: 3, completed_at: nil, created_at: nil, updated_at: nil>.part_of_velocity?` to return true, got false
# ./spec/models/task_spec.rb:27:in `block (3 levels) in <top (required)>’

I think something else needs to be changed to have the AR models get saved (all of their values are nil); will investigate.

where it says: Twitter has a Ruby gem that’s not to hard to set up, I think it should say: it’s not TOO hard to set up.

example security/02/gatherer/spec/models/user_spec.rb should use rails_helper instead of spec_helper as the tests use AR models

The tests do not pass:
——
Failures:

1) Project estimates can calculate remaining size
Failure/Error: expect(project.remaining_size).to eq(5)

expected: 5
got: 7
——

Task.initialize needs a line
——
mark_completed(Time.now) if option[:completed]
——

or the generation for :done in project_spec.rb should provide “completed_at: Time.now” instead of “completed: true”

Cheers,
Christoph

The two test descriptions use the word “test”. They should use “task” instead. Example: “considers a project with no test to be done” should be “considers a project with no task to be done”.

January 20th plus 6 months is July 20th, not June 20th.

dom class with underscore to make the test pass

On the 4th paragraph you say “…asserting that the title of the new task…” should be “…asserting the title of the new project”

On the 5th paragraph: “…only that the new task name is there.” should be ‘…only the new project name is there.’

I am not understanding how this test ensures that a task is not created:

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

Why would the expectation be that a task’s title is “size”?
I am thinking that the expectation would be to not see a task, e.g.

expect(creator.project.tasks.map(&:title)).to_not eq([“size”])
or
expect(creator.project.tasks).to be_empty

There seems to be an extra “:” in the factory girl example that uses an arbitrary class.

Regardless, I cannot get this factory running successfully:
FactoryGirl.define do
factory :specific_project, class: Project do
name “Project Runaway”
due_date { Date.today - rand(50) }
slug { “#{name.downcase.gsub(” “, ”_“)}” }
end
end

; it leads to this kind of error:
irb(main):001:0> FactoryGirl.create :specific_project
ArgumentError: Factory not registered: specific_project

but this factory is successful:
FactoryGirl.define do
factory :project do
name “Project Runaway”
due_date Date.parse(“2015-03-15”)
end
end

irb(main):004:0> FactoryGirl.create :project
(0.2ms) BEGIN
SQL (0.4ms) INSERT INTO “projects” (“created_at”, “due_date”, “name”, “updated_at”) VALUES ($1, $2, $3, $4) RETURNING “id” [[“created_at”, “2015-03-15 18:34:10.119105”], [“due_date”, “2015-03-15”], [“name”, “Project Runaway”], [“updated_at”, “2015-03-15 18:34:10.119105”]]
(2.6ms) COMMIT
=> #<Project id: 3, name: “Project Runaway”, due_date: “2015-03-15”, created_at: “2015-03-15 18:34:10”, updated_at: “2015-03-15 18:34:10”>

I think slug has to be defined in the Project model for this to work:

FactoryGirl.define do
factory :project do
name “Project Runaway”
due_date Date.parse(“2015-03-15”)
slug { “#{name.downcase.gsub(” “, ”_“)}” }
end
end

otherwise, I get the following error:

bundle exec rails console
irb(main):019:0> FactoryGirl.create(:project, name: “book to write”)
NoMethodError: undefined method `slug=’ for #

Regarding jasmine-fixture; please include install/setup/config information about this add-on library the linked to Github repo currently has no such information and given it’s reasonable to expect your readers to be new to this environment and it’s tools we could find it quite difficult to get a definitive answer, as things stand I think I’ve got mine working although I can’t be sure which specific action or combination of actions has provided the solution, after the clear instructions on how to install jasmine-rails it is rather cruel/lazy to then be left with no similar information on jasmine-fixture. Of course if I’ve missed something; please do let me know and I’ll retract my allegations of cruelty and laziness if not; then please get us the definitive information.

The definition starts with a call to RSpec::Matchers.define, pssing it, typo on pssing, should be passing.

In the code sample on page 130:

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

…did you perhaps mean:
expect(twin.first_name).to eq(“Paul”)

“a completed task is complete” —— test method is ‘task.complete!’ - actual method is ‘mark_completed’

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

expect(twin.first_name).to eq(“Paul”) would actually be correct here I believe.

In the second to the last paragraph, “…in the body of the specs.” should be “…in the bodies of the specs.”

In the fourth paragraph, in the phrase ``you can simulate that using the Rails helper fixure_file_upload(filename, mime_type), like this:’‘, the name of the Rails helper is misspelled; it should be ``fixture_file_upload’’.

At the bottom of [PDF] page 139, The last sentence is ``A full call to one of these methods has five arguments, though you’ll often just use the first three:’’ Immediately below this, at the very bottom of the page, we see what looks like a method call with four, not five arguments: ``get :show, {id: task.id}, {user_id: "3", current_project: project.id.to_s}, {notice: flash test}’’ In light of the second to last paragraph on the following page, it seems that the fourth argument, a hash of session key/value pairs, might be missing.

The “test” in the following two lines in the book should be “task”:

1) it “considers a project with no test to be done” do
2) it “knows that a project with an incomplete test is not done” do

In chapter 2 the project class has a done? method with the following code tasks.reject(&:complete?).empty?. It could be rewritten as tasks.all?(&:complete?) which I think reads better and prevents us from having to refactor the code and create the incomplete tasks method