Pragmatic Forums | Posts in forum 'Rails Test Prescriptions'

3.1 What is this symbol :db use for? posted by Dawid Stępień @ Wed, 24 Apr 2013 07:47:49 +0000

Dawid Stępień — Thu, 25 Apr 2013 11:57:18 +0000

3.1 What is this symbol :db use for? posted by Albert Yu @ Sat, 22 Sep 2012 23:01:06 +0000

Albert Yu — Sat, 22 Sep 2012 23:01:06 +0000

Why does this line of code work? posted by Charles de Bueger @ Thu, 19 Apr 2012 12:28:50 +0000

Charles de Bueger — Thu, 19 Apr 2012 12:28:50 +0000

Mocha Stub problem posted by Andrew Sage @ Sun, 21 Aug 2011 14:21:34 +0000

Andrew Sage — Sun, 21 Aug 2011 14:21:34 +0000

I’ve no idea what page it is as I’m viewing on a Kindle but it is 30% in.

When I added the “lets stub an object” test to project_test.rb I got the following error:

ProjectTest: test_lets_stub_an_object (0.06s) ERROR test_should_be_able_to_retrieve_projects_based_on_day (0.12s) NoMethodError: undefined method `assigns’ for # /Users/andrew/Rails/huddle/test/unit/project_test.rb:7:in `block in ‘

Any suggestions?

Why does this line of code work? posted by Danny O Cuiv @ Mon, 18 Jul 2011 18:52:20 +0000

Danny O Cuiv — Mon, 18 Jul 2011 18:52:20 +0000

status_date is an ActiveRecord attribute, which means that the accessors are generated, specifically a setter (status_date=) and a setter (status_date). When these are invoked from outside the class, there is no ambiguity

object.status_date = Date.today
and
foo = object.status_date

When you want to invoke them inside the class, the getter can be called unqualified, but you need to qualify the setter (with self), because of an ambiguity in the grammar. Specifically

status_date = Date.today

would look to the interpreter like an assignment to a local variable. Obviously you can qualify the getter too. It’s just that it’s not necessary.

Danny.

Why does this line of code work? posted by Noah Chase @ Fri, 15 Jul 2011 04:19:47 +0000

Noah Chase — Fri, 15 Jul 2011 04:20:43 +0000

I’m using the ePub formatted book, so I can’t give the best page number here. Roughly p.45—“The First Refactor”

Noel Rappin is fleshing out the StatusReport model to make the “saving a status report that has a date doesn’t override” test.

His code reads

def set_status_date
  self.status_date = Date.today if status_date.nil?
end

Instead, I expected to see

def set_status_date
  self.status_date = Date.today if self.status_date.nil?
end

, but it works as-is. I must be missing something basic here.

make class method posted by Jonathan Lim @ Mon, 04 Jul 2011 10:28:04 +0000

Jonathan Lim — Mon, 04 Jul 2011 10:28:04 +0000

PDF p.111, 112 code samples call Project.make

Should this be Project.new? If not, where is it defined?

Thanks,
Jon

Chapter 3 Test Errors Missing posted by Danny O Cuiv @ Fri, 03 Jun 2011 21:08:36 +0000

Danny O Cuiv — Fri, 03 Jun 2011 21:40:00 +0000

Hi James,

My guess from the above is that you have downloaded the code from the PragProg site and used that in your work-through. However, this code is for the completed example. What you needed to have done is to get a starting setup as explained in Appendix A: Sample Application Setup. I say this because your first two errors above are undefined method errors for a method called users on a Project instance. This method is being called on line 5 of your show view for projects. When I was working through the example, there was no users association in the Project model at that stage and the first few lines of the show view were like this:

<p id="notice"><%= notice %></p>

<p>
  <b>Name:</b>
  <%= @project.name %>
</p>

However, in the version from the code download, there is indeed a call to project.users on line 5 of the show view:

<% @project.users.each do |user| %>

The users association isn’t added until the top of page 243, much further on from where you are now. Oddly enough, this association is actually missing from the code download version. It should really be there.

Regards,

Danny.

Chapter 3 Test Errors Missing posted by James Strocel @ Wed, 01 Jun 2011 23:05:50 +0000

James Strocel — Wed, 01 Jun 2011 23:06:44 +0000

Hi There,

I was working my way through the book and I ran the tests for huddle3 as advised on page 55. Instead of getting this error:


1) Error: test_creation_of_status_report_with_data(StatusReportsControllerTest): ArgumentError: wrong number of arguments (1 for 0)     /test/functional/status_reports_controller_test.rb:58:in ✎to_s'     /test/functional/status_reports_controller_test.rb:58:in      ✎test_creation_of_status_report_with_data'

I get these errors:


1) Error:
test_index_should_display_project_timeline(ProjectsControllerTest):
ActionView::Template::Error: undefined method `users' for #<Project:0x102c59bc8>
    app/views/projects/show.html.erb:5:in `_app_views_projects_show_html_erb__1391822682_2176008960_0'
    app/controllers/projects_controller.rb:26:in `show'
    /test/functional/projects_controller_test.rb:73:in `test_index_should_display_project_timeline'

  2) Error:
test_project_timeline_index_should_be_sorted_correctly(ProjectsControllerTest):
ActionView::Template::Error: undefined method `users' for #<Project:0x10351df98>
    app/views/projects/show.html.erb:5:in `_app_views_projects_show_html_erb__1391822682_2176008960_0'
    app/controllers/projects_controller.rb:26:in `show'
    /test/functional/projects_controller_test.rb:63:in `test_project_timeline_index_should_be_sorted_correctly'

  3) Error:
test_should_get_edit(ProjectsControllerTest):
ActionView::Template::Error: undefined method `projects' for #<User:0x1031ae678>
    app/views/projects/edit.html.erb:12:in `_app_views_projects_edit_html_erb__1954596551_2173714420_0'
    app/views/projects/edit.html.erb:8:in `each'
    app/views/projects/edit.html.erb:8:in `_app_views_projects_edit_html_erb__1954596551_2173714420_0'
    /test/functional/projects_controller_test.rb:44:in `test_should_get_edit'

  4) Error:
test_should_show_project(ProjectsControllerTest):
ActionView::Template::Error: undefined method `users' for #<Project:0x102f0fdb8>
    app/views/projects/show.html.erb:5:in `_app_views_projects_show_html_erb__1391822682_2176008960_0'
    app/controllers/projects_controller.rb:26:in `show'
    /test/functional/projects_controller_test.rb:39:in `test_should_show_project'

  5) Error:
test_should_update_project(ProjectsControllerTest):
NoMethodError: undefined method `users=' for #<Project:0x102d56760>
    app/controllers/projects_controller.rb:69:in `update'
    /test/functional/projects_controller_test.rb:49:in `test_should_update_project'

  6) Error:
test_should_update_with_users(ProjectsControllerTest):
StandardError: No fixture with name 'quentin' found for table 'users'
    /test/functional/projects_controller_test.rb:90:in `test_should_update_with_users'

Am I doing something wrong here or did I use the wrong code sample?

Keep up the good work!

-James

Fixtures bypassing ActiveRecord posted by Danny O Cuiv @ Fri, 27 May 2011 20:57:06 +0000

Danny O Cuiv — Fri, 27 May 2011 20:57:06 +0000

I’m going to bump this one if that’s OK. (It’s been almost two weeks and 130 views.)

Anyone got any idea what was being referred to here?

Thanks,

Danny.

Framework? posted by Danny O Cuiv @ Wed, 25 May 2011 08:01:21 +0000

Danny O Cuiv — Wed, 25 May 2011 08:02:34 +0000

From page 16 of the print edition:

For its part, Rails smooths out the difference between minitest and Test::Unit 1.3 and adds its own features on top of both. For our purposes, we don’t need to worry about the difference, and to minimize confusion (too late?), I’ll continue to refer to that library as Test::Unit. Since I’m boldly assuming you are writing a Rails application, I’m not going to sweat the difference between what’s in Rails and what’s in Test::Unit. Test::Unit 2.0 doesn’t seem to have much of a constituency at the moment, so I’m going to ignore it.

Danny

Framework? posted by Ron Green @ Tue, 24 May 2011 22:28:57 +0000

Ron Green — Tue, 24 May 2011 22:28:57 +0000

Does this cover Test::Unit or MiniTest or either

Zebra missing? posted by Noel Rappin @ Sat, 21 May 2011 23:08:04 +0000

Noel Rappin — Sat, 21 May 2011 23:08:04 +0000

Try

https://github.com/jamesgolick/zebra

Fixtures bypassing ActiveRecord posted by Danny O Cuiv @ Sun, 15 May 2011 12:24:11 +0000

Danny O Cuiv — Sun, 15 May 2011 12:25:42 +0000

Thanks Noel for your answer to my previous question. I’ve got another. On page 77 of the print edition (or page 83 of the PDF), you say:

This means you can’t use arbitrary methods of the model as attributes in the fixture the way you can in a create( ) call. Fixture attributes have to be either actual database columns or ActiveRecord associations explicitly defined in the model.

This implies to me that things like virtual attributes are allowed in a call to create, whereas fixtures are restricted to actual database columns (and associations). I was curious and looked this up in the API. create() just calls new() before saving and in the documentation for the new() method, it states:

In both instances, valid attribute keys are determined by the column names of the associated table – hence you can’t have attributes that aren’t part of the table columns.

This seems to me to be at odds with you wrote above. Can you clarify?

Thanks,

Danny.

Zebra missing? posted by Christian Schell @ Thu, 14 Apr 2011 15:39:57 +0000

Christian Schell — Thu, 14 Apr 2011 15:39:57 +0000

Hey,
just wanted to try Shoulda with Zebra, but “gem ‘zebra’” in a rails3-app doesn’t work:
“Could not find gem ‘zebra (>= 0, runtime)’ in any of the gem sources listed in your Gemfile.”
Even gem search ‘zebra’ wasn’t successfull. Do I need more than that entry in the gemfile?
CS

Strange passage on page 48 posted by Noel Rappin @ Wed, 06 Apr 2011 22:27:40 +0000

Noel Rappin — Wed, 06 Apr 2011 22:27:40 +0000

Following up. Since status_date is a Date in the database, the type issue is not a problem in this case. It would be if you were using created_at.

So this text seems to be totally out of sync with the example it is near.

I’m sorry about that. I’ll put an errata in so that it will be clarified in the text.

Thanks for letting me know about this issue.

Noel

Strange passage on page 48 posted by Noel Rappin @ Wed, 06 Apr 2011 22:06:23 +0000

Noel Rappin — Wed, 06 Apr 2011 22:06:23 +0000

It’s a badly phrased passage.

Well, it’s a passage that seems to have been moved out of it’s original context, and doesn’t make sense where it is.

The text in question really applies largely to controller testing, as the following paragraph in the book suggests. I suspect this paragraph that is confusing you was originally placed near a controller test, but got moved, and it’s meaning got garbled.

The problem that you try to solve with reload is this:

1. You create an instance of an object in a test, and save it to the database, call this instance “foo”

2. You then make a call into the application, where that object is read from the database into a new Ruby object, call it “bar”. This is most common when you create an object, and then call, say, the show method of a controller via the ID, the controller reads the object from the database and creates a new object in memory backed by the same database row. (That’s what I mean by “creates a new instance from the database”, which, again, doesn’t actually apply to the example as I said it does.)

3. You make changes to instance “bar” in the code, and those changes get saved to the database

4. Now in the test, you still have a reference to “foo”, but “foo” does not have the changes made to “bar” and saved to the database, because they are two different objects. You call “reload” to allow the “foo” instance to have changes made to “bar”.

Now, about the typecast issue. I believe that what I was trying to guard against is that when you create the instance from the ActiveRecord code, the status_state is a Date object, but when you read one from the database, it is a DateTime object, so you need to change one into the other in order to do a comparison. Your IRB snippet is correct, but if you had done a create on the object, and then read it back out of the database, the status_date.class would be a DateTime. I can’t completely recreate this right now, but I’ll give it a try later and report back.

Sorry about the confusion—I think this one should have been caught.

Noel

Strange passage on page 48 posted by Danny O Cuiv @ Tue, 05 Apr 2011 13:33:17 +0000

Danny O Cuiv — Tue, 05 Apr 2011 13:33:17 +0000

I’m going to bump this one, if that’s OK. It’s had a good number of eyeballs at this stage, but nobody’s replied. Which either means that it’s a really basic question or it’s a really badly phrased passage.

Let me simplify my question. An object is created with attribute called status_date that is of type Date. It’s saved to the database. After retrieval, you will still get a Date object if you read the attribute. In what sense is there any kind of “typecast” happening here?

If anyone has any insights, I’d be very grateful.

Danny.

Strange passage on page 48 posted by Danny O Cuiv @ Fri, 01 Apr 2011 16:18:51 +0000

Danny O Cuiv — Fri, 01 Apr 2011 16:18:51 +0000

Hi,

I’ve been reading the book and enjoying the approach, but am stumped by a passage on page 48. Can anyone who has read the book enlighten me? The passage is:

“In this particular case, the controller creates a new instance from the database and saves that instance, without touching the actual variable created for the test. As a result, the database version has typecast the status_date to a Date when saving, but the live version in memory hasn’t gotten that change.”

So, my difficulties are:

(i) The controller creates a new instance from a hash, not from the database. (I can’t even think what creating a new instance from the database could mean.)

(ii) I’m not sure what is meant by saving the instance without touching the variable. The call is:
actual.save
Does this constitute not “touching” the variable?

(iii) Most puzzling of all is the bit about the database version having typecast the status_date to a Date when saving. As far as I can see, status_date was a Date right from the time the value appeared in the hash. Playing around on the console gives:

actual = StatusReport.new(:status_date => 10.days.ago.to_date)
=> #
>> actual.status_date.class
=> Date

So that status_date was always a Date. What’s meant by it being “typecast” to a Date?

Thanks in advance,

Danny.

Sec 3.1: Why not change the default "should create status_report" in status_reports_controller_test.rb posted by Alexander Maiburg @ Wed, 09 Mar 2011 08:08:03 +0000

Alexander Maiburg — Wed, 09 Mar 2011 08:08:03 +0000

Is there any chance to get an answer?

Alex

Sec 3.1: Why not change the default "should create status_report" in status_reports_controller_test.rb posted by Alexander Maiburg @ Fri, 04 Mar 2011 11:20:09 +0000

Alexander Maiburg — Fri, 04 Mar 2011 11:20:09 +0000

In my opinion the default test “should create status_report” and the new added test “creation of status report with data” do very similar things.

So, why did you decide to put the logic for testing the creation of a status report in another test?
Isn’t the default test obsolete?

TIA, Alex

Shoulda fails with missing translations posted by Justin Case @ Wed, 23 Feb 2011 15:45:47 +0000

Justin Case — Wed, 23 Feb 2011 15:46:17 +0000

When trying to test validations shoulda kept throwing me Expected block to return true value even though the validations were present in the model. Turns out that I was missing a locale translation. After adding the missing translation the tests ran fine.

Hopefully this might save someone a few hours.

mobi version chapter number posted by Noel Rappin @ Sun, 06 Feb 2011 22:17:27 +0000

Noel Rappin — Sun, 06 Feb 2011 22:17:27 +0000

I’m pretty sure that’s an artifact of the beta process—the beta changelog is listed as chapter 1.

mobi version chapter number posted by Keith Bawden @ Sun, 06 Feb 2011 14:13:15 +0000

Keith Bawden — Sun, 06 Feb 2011 14:13:15 +0000

The mobi version b11_0 chapter numbers appear to be incorrect. Numbering begins from 2.

One-liner shoulda syntax using braces posted by Noel Rappin @ Sun, 02 Jan 2011 16:30:09 +0000

Noel Rappin — Sun, 02 Jan 2011 16:30:09 +0000

Sorry for not getting to this sooner, I was away.

I need to poke at this a little bit, this may be a mistake on my part in trying to get the example to take up fewer line. I think that the proper way to rewrite this as a one-liner is:

should(“be successful”) { assert_response :success }

Or use the shoulda macro:

should respond_with(:success)

Thanks,

Noel