Re: [rspec-users] Testing Rails Associations
On 7/3/07, Daniel N [EMAIL PROTECTED] wrote: Hi, I'm very new to rspec, so if this is not the right forum please let me know. I'm starting to spec my models first in an existing rails app, porting from a mix of Test::Unit, and simply_bdd amongst others. I'm at the point where I want to test that certain associations are present. What I'm not sure of is should I test the association or the method and return object. That is, if I wanted to test a has_many should I: Confirm the methods exist, and that the return an array etc OR Check that the model has the named has_many association through it's reflections. On one hand the second one looks like it will be a bit more robust, since if there is a has_many relationship, then all the associated methods may be used througout the app. This would put testing in the one place. On the other hand, this would be really testing the implementation of the model rather than it's behaviour. The behaviour is to call @article.comments and have an array of comments returned. Any thoughts? I think the jury is still out on this one. Both approaches present problems, and no better approaches have been proposed. I'd say try it both ways and report back on experiences. David Cheers Daniel ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] mocking methods in the controller.
On 7/5/07, Daniel N [EMAIL PROTECTED] wrote: Hi, I'm very new to rspec so please be patient with me. I've tried to take some of my tests out of the controller specs to check for things that are rendered. This has not worked so well, since my views have the controller method current_user in quite a few places. Is there any way that I can define this so that my views will be executed? Will this same thing occur for all helper methods that are definied in the controller? If I understand you correctly, you are trying to take tests for views that were previously rails functional tests and turn them into rspec view examples. If that is the case, you should be able to do this: template.stub!(:current_user).and_return(mock_model(User)) If not, please provide an explicit example so we can better understand what you're talking about. Cheers, David Cheers Daniel ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] mocking methods in the controller.
On 7/6/07, Daniel N [EMAIL PROTECTED] wrote: On 7/6/07, Daniel N [EMAIL PROTECTED] wrote: On 7/6/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/5/07, Daniel N [EMAIL PROTECTED] wrote: Hi, I'm very new to rspec so please be patient with me. I've tried to take some of my tests out of the controller specs to check for things that are rendered. This has not worked so well, since my views have the controller method current_user in quite a few places. Is there any way that I can define this so that my views will be executed? Will this same thing occur for all helper methods that are definied in the controller? If I understand you correctly, you are trying to take tests for views that were previously rails functional tests and turn them into rspec view examples. If that is the case, you should be able to do this: template.stub!(:current_user).and_return(mock_model(User)) If not, please provide an explicit example so we can better understand what you're talking about. Cheers, David Thanx David, That looks like what I was looking for. I will try it when I get home. Cheers Daniel Ok I've started to have a crack at this but it's getting way out of hand. Everytime I stub a method there's another one to do. I've also found that when there's a partial _detail and I've passed the :collection = @things to it it blows up complaining that the local variable is nil in dom_id( detail ) If you're using the trunk, you can do this: template.expects_render(:partial = 'detail', :collection = @things) Am I doing someting wrong? The start of my specs is before do @u = mock_model( User ) @book = mock_model( Book ) public_book = mock_model( Book ) private_book = mock_model( Book ) public_book.stub!(:title=).and_return( Public Title ) private_book.stub!(:title=).and_return( Private Title ) public_book.stub!( :title ).and_return( Public Title ) private_book.stub!( :title ).and_return( Private Title ) Why are you stubbing the same calls twice each? @u.stub!( :public_books ).and_return( [public_book] ) @u.stub!( :private_books ).and_return( [private_book] ) @clip = mock_model( Clip ) @clip.stub!( :id ).and_return( 1 ) @clips = [ @clip ] template.stub!( :current_user ).and_return( @u ) end and I've only started. Is it normal to have to stub this much for a view? Depends on how much stuff is in your view :) You've got a couple of options. You could create instances of the model instead. As long as you're not saving and retrieving them there's very little db interaction - just enough for AR to discover the attributes. If you prefer to keep it all mocked/stubbed, you could clean up a bit like this: before do @u = mock_model( User ) @book = mock_model( Book ) public_book = mock_model(Book, :title = 'Public Title') private_book = mock_model( Book, :title = 'Private Title') @u.stub!( :public_books ).and_return( [public_book] ) @u.stub!( :private_books ).and_return( [private_book] ) @clips = [ @clip = mock_model( Clip, :id = 1 ) ] template.stub!( :current_user ).and_return( @u ) end That stubs the same amount of stuff, but its a little cleaner. You could also write a shared behaviour that stubs current user: describe authenticated page view, :shared = true do before(:each) do template.stub!( :current_user ).and_return( @u ) end end describe /some/page it_should_behave_like authenticated page view before(:each) do @u = mock_model( User ) @book = mock_model( Book ) public_book = mock_model(Book, :title = 'Public Title') private_book = mock_model( Book, :title = 'Private Title') @u.stub!( :public_books ).and_return( [public_book] ) @u.stub!( :private_books ).and_return( [private_book] ) @clips = [ @clip = mock_model( Clip, :id = 1 ) ] end end There's probably a bit more to clean up but I'd have to see the view code. Would you mind letting us see it? Cheers Daniel ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Mocking User.find( :all, :limit = 10 )
On 7/9/07, Josh Knowles [EMAIL PROTECTED] wrote: On 7/9/07, Johan Sørensen [EMAIL PROTECTED] wrote: Is there a way in RSpec to check for a specific hash key (or evaluating other things along those lines) in the parameter expectation using the should_receive(:find).with(...) construct? As opposed to getting into complicated mocking scenarios, consider abstracting this logic into your model: http://blog.caboo.se/articles/2007/6/19/rspec-notes-from-the-trenches-2 Agreed that this is a good approach in terms of dealing w/ rails models. As for the question of isolating specific key/value pairs in a hash, you could do this: obj.should_receive(:message) do |*args| hash = args.pop hash[interesting_key].should == expected_value end It's not pretty, but it works. The other thing you might consider is a custom matcher. Something like: obj.should_receive(:message).with(has_key_value(key, value)) The mock framework can use these just as the expectation framework - though mocks rely on == instead of matches. David -- Josh Knowles [EMAIL PROTECTED] http://joshknowles.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] they synonym for it?
On 7/11/07, Ashley Moran [EMAIL PROTECTED] wrote: On 11 Jul 2007, at 15:00, Pedro Del Gallego wrote: Thats my biggest problem with rspec, (I'm a non english speaker working in a German/English environment) It would be great a guide or a tips list to make our specs more readebles, Something like 10 English tips to improve your specs readability ;) Don't think I can come up with 10 off the top of my head but I always told Pawel to follow the rule phrase descriptions as GIVEN WHEN THEN. There's plenty of better examples on this list and elsewhere, but basically if I have an idea like this: A cow prodded with a stick should moo I think: GIVEN=a cow, WHEN=prodded with a stick, THEN=moo and turn it into this code: describe Cow do before(:each) do @cow = Cow.new end it 'should say moo when sent prod_with_stick' do @cow.prod_with_stick.should == moo end end It doesn't apply rigidly to every situation, but 90% of the time, if I keep chanting GIVEN WHEN THEN I write clean, focussed specs. The rest is mainly vocabulary (although sometimes it can be hard to phrase something clearly). I've been in that habit too. In general, I want the GIVEN expressed in the String passed to describe and/or before(:each). The WHEN and THEN should be in the example. As Ashley suggests, this isn't 100% of the time, but I find that the more I stick to this the easier it is to grok everything when looking back. Also, I try to stick to one WHEN and one THEN per example. This means that if there are mocks involved, my examples generally look like this: it should foo when bar do collaborator.should_receive(:baz) thing.bar end OR it should foo when bar do thing.bar thing.baz.should == something end BUT NEVER it should foo when bar do collaborator.should_receive(:baz) thing.bar thing.fu.should == something end FWIW. Cheers, David Ashley ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] they synonym for it?
On 7/13/07, Ashley Moran [EMAIL PROTECTED] wrote: On 12 Jul 2007, at 17:20, Anthony Carlos wrote: If you guys don't mind, I'm going to create a sample web page with this concept on it, stealing from Ashley and David's writings. If people like it, perhaps we can get it included in the documentation. Do you have a wiki you could use? If not I could open a public page on my company's wiki and you could edit it there - might be easier to do collaborative stuff that way. We don't right now, nor do we have resources to set one up, so if you can set something up that would be awesome. Thanks Ashley, David Ashley ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specing Layouts
On 7/14/07, Daniel N [EMAIL PROTECTED] wrote: Hi, I've just started to try and spec my application.html.erb layout as one of the view specs but it totally barfs. I'm guessing that it's due to the yield statements in the layout. Any clues as to how to proceed? Backtrace please? Could be any number of things. Cheers Daniel ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Mocking Rails association collections
On 7/18/07, Paul [EMAIL PROTECTED] wrote:
Rails model association collections allow you to do nifty things like:
article.comments.find(:all, :conditions = {:created_at 1.day.ago})
Has anyone found a good way to mock this up? I'm currently doing this:
@comment1 = mock_model(Comment)
comments = mock(Array)
comments.stub!(:find).and_return([EMAIL PROTECTED])
@article = mock_model(Article)
@article.stub!(:comments).and_return(comments)
I don't like this, because of that intermediate 'comments' object, whose
only purpose is so that i can stub the chained method. I'd like to do
something like this:
@comment1 = mock_model(Comment)
@article = mock_model(Article, :comments = mock(Array, :find =
[EMAIL PROTECTED]))
But trying this causes an error: Mock 'Array' received unexpected
message :find with (:all, ...) because you can't inline stubs with
ordinary `mock`. I can replace it with `mock_model`, but this feels unclean.
Has anyone come across a good 'best-practice' solution to this problem?
You can use the stub() method instead of mock() to inline method stubs:
@article = mock_model(
Article, :comments = stub(Array, :find = [EMAIL PROTECTED])
)
The mock() method works differently because it does different stuff w/
the Hash under the covers.
TIA,
Paul Sadauskas
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Rails - Mock going out of scope?
On 7/18/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: Hello list, I think I have a rails related RSpec problem with a mock going out of scope on a recursive call to a model. The code is at: http://pastie.textmate.org/79821 if you want to see it highlighted. I have pasted it below as well. Basically, I have an acts_as_nested_set model called Node, which works fine. I have a function which finds the language name of the node instance. If the language is nil for the node instance being queried, it then recursively calles language_name on it's parent until one of them has the language. Then this gets returned. When I do this with a fixture, it works fine. Ie, a Database call can be made to a language table and I get the language name. In the code attached it has a langauge instance being mocked. I get the same result if I mock Language.should_receive(:find)... It SEEMS like the Mock is going out of scope on the recursive call to parent. The direct spec to the parent to get language name works fine. Any ideas? (the code below is slimmed down to the code needed to run the spec. Regards Mikel CODE:: class Node ActiveRecord::Base belongs_to :language acts_as_nested_set :scope = :root_id def language_name self.root? ? language.name : parent.language_name end end describe Node, instance do fixtures :nodes before(:each) do @language = mock_model(Language, :name = Japanese) @node = Node.create!(:language = @language) @section1 = Node.create!() @chapter1 = Node.create!() end it should return it's own language if it is root do # Passes @language.should_receive(:name).exactly(:once).and_return(Japanese) @node.language_name.should == Japanese end it should return it's parent's language if it is a child do # Fails (message below) @section1.move_to_child_of(@node) @chapter1.move_to_child_of(@section1) @language.should_receive(:name).exactly(:once).and_return(Japanese) @section1.language_name.should == Japanese @language.should_receive(:name).exactly(:once).and_return(Japanese) @chapter1.language_name.should == Japanese end end It's generally not recommended that you set expectations, invoke them and then set them again. I'm not sure, but that may be the problem here. Try this: it should return it's parent's language if it is a child do # Fails (message below) @section1.move_to_child_of(@node) @chapter1.move_to_child_of(@section1) @language.should_receive(:name).exactly(:twice).and_return(Japanese) @section1.language_name.should == Japanese @chapter1.language_name.should == Japanese end Does that work? SPEC ERROR:: NoMethodError in 'Node instance should return it's parent's language if it is a child' You have a nil object when you didn't expect it! The error occurred while evaluating nil.name /Users/mikel/working/universal_translator/config/../app/models/node.rb:29:in 'language_name' /Users/mikel/working/universal_translator/config/../app/models/node.rb:29:in 'language_name' ./spec/models/node_spec.rb:160: script/spec:4: ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Rails - Mock going out of scope?
Here are the errors I'm getting now: 1) NoMethodError in 'Node instance should return it's parent's language if it is a child' undefined method `move_to_child_of' for #Node:0x34d3110 ./spec/models/node_spec.rb:20: 2) NameError in 'Node instance should return it's own language if it is root' undefined local variable or method `parent' for #Node:0x34b8ef0 /Users/david/projects/ruby/nodes/config/../app/models/node.rb:7:in `language_name' ./spec/models/node_spec.rb:16: What version of rails are you using? And is there a plugin you're using for nested set? David On 7/19/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: Here are the migrations: class CreateNodes ActiveRecord::Migration def self.up create_table (nodes, :options = 'ENGINE=InnoDB DEFAULT CHARSET=utf8', :force = true) do |t| t.column title,:string t.column language_id, :integer t.column parent_id,:integer t.column lft, :integer t.column rgt, :integer t.column original_node_id, :integer t.column owner_id, :integer t.column owner_type, :string t.column root_id, :integer end end def self.down drop_table nodes end end class CreateLanguagesTable ActiveRecord::Migration def self.up create_table (:languages, :options = 'ENGINE=InnoDB DEFAULT CHARSET=utf8', :force = true) do |t| t.column :name, :string end end def self.down drop_table :languages end end The Nodes Model also has a self referrential association, but I don't think that would be causing any problems. class Node ActiveRecord::Base belongs_to :language belongs_to :owner, :polymorphic = true # Self referrential association, nodes have many original nodes - keeps track # of all original = translation associations belongs_to :original_node, :class_name = Node, :foreign_key = original_node_id has_many :translated_nodes, :class_name = Node, :foreign_key = original_node_id acts_as_nested_set :scope = :root_id # + code from the original pastie end There are some other associations, but they are all belongs_to or has_many, so I haven't bothered to put all the tables in here and have removed the appropriate foreign keys from the nodes table. Regards Mikel On 7/19/07, David Chelimsky [EMAIL PROTECTED] wrote: Would you mind posting the migrations? On 7/18/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: Heya David, Thanks for the reply. No, that didn't work, get the same error: NoMethodError in 'Node instance should return it's parent's language if it is a child' You have a nil object when you didn't expect it! The error occurred while evaluating nil.name If I include the fixture :languages, then replace out @language = mock_model... with @language = languages(:one) it all works dandy. But I'm trying to ween myself off fixtures :) Regards Mikel On 7/19/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/18/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: Hello list, I think I have a rails related RSpec problem with a mock going out of scope on a recursive call to a model. The code is at: http://pastie.textmate.org/79821 if you want to see it highlighted. I have pasted it below as well. Basically, I have an acts_as_nested_set model called Node, which works fine. I have a function which finds the language name of the node instance. If the language is nil for the node instance being queried, it then recursively calles language_name on it's parent until one of them has the language. Then this gets returned. When I do this with a fixture, it works fine. Ie, a Database call can be made to a language table and I get the language name. In the code attached it has a langauge instance being mocked. I get the same result if I mock Language.should_receive(:find)... It SEEMS like the Mock is going out of scope on the recursive call to parent. The direct spec to the parent to get language name works fine. Any ideas? (the code below is slimmed down to the code needed to run the spec. Regards Mikel CODE:: class Node ActiveRecord::Base belongs_to :language acts_as_nested_set :scope = :root_id def language_name self.root? ? language.name : parent.language_name end end describe Node, instance do fixtures :nodes before(:each) do @language = mock_model(Language, :name = Japanese) @node = Node.create!(:language = @language) @section1 = Node.create!() @chapter1 = Node.create!() end it should return it's own language if it is root do # Passes
Re: [rspec-users] File.stub!
On 7/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I've answered my own question. I changed before :all do; to just before
do (which is the same as before :each do) and everything works fine. I'm
not overly concerned that stubbing has to occur prior to each example
method, but why is this the case? If this behaviour is intended (which
I'm guessing it is), then perhaps this should make its way into the
docs?
There's an open RFE to deal w/ better integrating before(:all) with
everything else:
http://rubyforge.org/tracker/?func=detailgroup_id=797aid=10696atid=3152
Tim Watson
Technologist
BT Web21C SDK
Email: [EMAIL PROTECTED]
Cell: +44 7918 711 612
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: 27 July 2007 08:27
To: rspec-users@rubyforge.org
Subject: Re: [rspec-users] File.stub!
Hi,
I'm trying to stub File.open and whenever I do, rspec blows up with the
following error message (undefined method `add' for nil:NilClass), which
seems to happen because method __add in class Proxy is calling #add on
global $rspec_mocks, which in turn is nil.
Can someone explain what I'm doing wrong, as I can't seem to stub
anything out! Here's my code:
class Foo
def Foo.open( name, mode )
return name
end
end
describe Something, 'blah blah' do
class FooDouble #:nodoc:
attr_reader :data
def initialize
@data = []
end
def method_missing( name, *args )
puts ignoring call to #{name} with args [#{args.each |arg|
arg.inspect}]
end
def (raw_data)
@data.push raw_data
end
end
before :all do
Foo.stub!( :open ).and_return( FooDouble.new )
#have also tried and_return { FooDouble.new }
end
...
end
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] autotest doesn't notice file changes
On 7/27/07, Ingo Weiss [EMAIL PROTECTED] wrote: Hi all, I am trying to use autotest with rspec and rais, and it seems to work fine when I run autotest -rails initially, but then autotest fails to recognize file changes and run tests continuously. Did I skip a step? Here is my setup: rails v1.2.3 rspec plugin v1.0.5 rspec_on_rails plugin v1.0.5 ZenTest gem v3.6.1 Leave off -rails. Just type autotest Thanks for any help with fixing this! Ingo ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Rspec on rails with out database?
On 7/24/07, Eric Pugh [EMAIL PROTECTED] wrote: Hi all, I am trying to use rspec_on_rails in a Rails app that doesn't have a database. so far I have just been faking it out by dumping in a sqlite3 database just to make Rails happy. Try deleting config/database.yml (or renaming it to something else) and then running: rake spec That should do it. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Rspec on rails with out database?
On 7/27/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/24/07, Eric Pugh [EMAIL PROTECTED] wrote: Hi all, I am trying to use rspec_on_rails in a Rails app that doesn't have a database. so far I have just been faking it out by dumping in a sqlite3 database just to make Rails happy. Try deleting config/database.yml (or renaming it to something else) and then running: rake spec That should do it. I take it back. It doesn't work. There is an open RFE on making this work - perhaps it's time to address it. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Isolating rails model specs from their implementation
On 7/29/07, Russell Tracey [EMAIL PROTECTED] wrote:
On 29/07/07, David Chelimsky [EMAIL PROTECTED] wrote:
On 7/29/07, Russell Tracey [EMAIL PROTECTED] wrote:
I'm currently taking a Rails project management app I built when
learning Rails and adding specs to it. During the course of building
the app the requirement that project should be archiveable was added.
So a project is in one of two states active or archived.
This led to the creation of the following methods:
Project.active_projects
Project.archived_projects
@project.active?
@project.archived?
@project.archive!
@project.unarchive!
The current implementation of this is using a separate table of
visibilities as follows:
# Implementation 1 (Current)
Tables:
Project
id name visibility_status_id
1 ActiveProject1
1 ArchivedProject 2
VisibilityStatuses
id name
1 Live
2 Archived
But the same behavior could be implemented using a datetime column as
follows:
# Implementation 2
Tables:
Project
id namearchived_at
1 ActiveProject null
1 ArchivedProject 2007-07-29:18:57
Or in fact numerous other ways e.g.
# Implementation 3
Army of cows:
Each cow represents a project, the cows wear one of two hats
to indicate the active/archived status of the project they represent.
...and so on.
It's my understanding that model specs (and specs in general) should
be shielded from the implementation details, so how do i check that
Project.active_projects only returns active projects without looking
at assuming something about the implementation? My initial thought is
to check each of them using one of the other exposed methods above, in
this case...
Project.active_projects.all? {|p| p.active? }
but then i can't work out how to spec all the other methods without
going round in circles so that each spec would end up assuming that
the other methods work (in this case that p.active? is working) or
worse resorting to peeking at implementation details.
Keep in mind that back-filling examples to existing code is a very
different process from writing the examples first, which is the
situation for which RSpec is intended. In that case, you might start
with one example like this:
describe Project do
it should not be active by default do
project = Project.create
project.should_not be_active
end
end
Then the next example might be that when you activate it should be active:
describe Project do
it should not be active by default { ... }
it should be active after you activate it do
project = Project.create
project.activate!
project.should be_active
end
it should show up in the list of active projects when activated do
project = Project.create
project.activate!
Project.active_projects.should include(project)
end
end
etc.
In this second pair of examples, we never test the activate! method
in terms of looking at its internal effects (i.e. that it changes
something in the database), but rather through the difference in the
way the object behaves after having called the activate! method.
Make sense?
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Yes this is making more sense now, the only remaining thing i am
wondering is, given the above examples, would specing that
active?/archived? be possible without resorting to implementation
details that Kyle wrote about. If i'm reading them correctly the
examples above spec out the behavior of activate!, active_projects and
the default state of a project after creation, but don't define the
behavior of active?
In this app the projects are actually active by default before being
archived at some point later. So they are only ever in one of two
states, active or archived.
I'm thinking something like this
describe Project do
...
it Not sure what this would be called? do
project = Project.create
project.should be_active
project.archive!
project.should_not be_active
end
end
Changing state between expectations in one example is a TDD no-no. The
reason is that if project.should be_active fails, you might do
something to fix it and then find that project.should_not be_active
fails. If you have them in separate examples then the fact that only
one fails and not the other gives you better feedback:
describe Project do
it should be active when first created do
project = Project.create
project.should be_active
end
it should not be active after it is archived do
project = Project.create
project.archive!
project.should_not be_active
Re: [rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec
On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: I find myself doing the same thing... the, open the model and type in the it shoulds... I ws thinking along the same line... probably all that would be needed is a rake task that hooks into the Mock class and runs all the specs taking not of all the stubs and mocks method calls that are made. Then it could PRODUCE the it shoulds... @model = mock_model(People, :id = 1, :name = Bob) @model.should_receive(:alive?).and_return(true) # rake spec:find_fakes produces: describe People automatically do it should have a name it should respond to alive? end Now... that would be cool I would tend to disagree. RSpec is a Behaviour Driven Development tool. The idea is that you write a small example of behaviour FIRST, and use that example to drive the implementation. The reason you use examples to drive implementation comes from the idea in Test Driven Development that it will lead to tighter, more focused and more flexible implementations. If your examples come after the code, whether they are generated or you write them yourself, then you are losing out quite a bit of value of the process with which RSpec is aligned. Secondly, having a name is not behaviour. Using it might be. Or how you set it might be. For example: describe Thing do it should use the first initializer argument as its name do Thing.new(João).name.should == João end it should be alive when first created do Thing.new.should be_alive end end Implicit in these examples are the fact that Thing has a name and responds to alive?, but those are just artifacts in support of the behaviour. That all make sense? In a fairly abstract way. But how do you keep track of what methods have been stubbed or mocked? From the above Thing.new.alive? will need to be defined. This seems to be the spec for Thing, but if in a view I said it should do_stuff if @thing is alive do @thing = mock_model( Thing ) @thing.stub!( :alive? ).and_return( true ) controller.should_receive( :do_stuff ) do_get end How do I run the view first without Thing, If you're using mock_model and the constant Thing, then you have to create Thing to get that example to run. Admittedly, having to create that model class is a distraction from the flow, but it is a very small distraction that has never really bothered me that much. I imagine that we could tweak mock_model to accept a String, or perhaps somebody with stronger TextMate chops than mine could submit a patch to the TextMate bundle that would let you click on Thing and create a Thing model. and also keep track of alive? being decalred on the Thing instance? This is something that has come up on this list and in RFEs a few times. The most promising idea is to have a command line switch that would look at any mock that was passed a class name and ensure that the class responds to any mocked or stubbed methods. But even that would fall apart as soon as you start using any metaprogramming techniques to change the nature of an object at runtime. For me, the answer to keeping track of mocked methods is automated end-to-end tests. Either in browser, or something like Rails' integration tests (assuming Rails), or (soon) rbehave's story runner (which is now being integrated into rspec). Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec
On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: I find myself doing the same thing... the, open the model and type in the it shoulds... I ws thinking along the same line... probably all that would be needed is a rake task that hooks into the Mock class and runs all the specs taking not of all the stubs and mocks method calls that are made. Then it could PRODUCE the it shoulds... @model = mock_model(People, :id = 1, :name = Bob) @model.should_receive(:alive?).and_return(true) # rake spec:find_fakes produces: describe People automatically do it should have a name it should respond to alive? end Now... that would be cool I would tend to disagree. RSpec is a Behaviour Driven Development tool. The idea is that you write a small example of behaviour FIRST, and use that example to drive the implementation. The reason you use examples to drive implementation comes from the idea in Test Driven Development that it will lead to tighter, more focused and more flexible implementations. If your examples come after the code, whether they are generated or you write them yourself, then you are losing out quite a bit of value of the process with which RSpec is aligned. Secondly, having a name is not behaviour. Using it might be. Or how you set it might be. For example: describe Thing do it should use the first initializer argument as its name do Thing.new(João).name.should == João end it should be alive when first created do Thing.new.should be_alive end end Implicit in these examples are the fact that Thing has a name and responds to alive?, but those are just artifacts in support of the behaviour. That all make sense? In a fairly abstract way. But how do you keep track of what methods have been stubbed or mocked? From the above Thing.new.alive? will need to be defined. This seems to be the spec for Thing, but if in a view I said it should do_stuff if @thing is alive do @thing = mock_model( Thing ) @thing.stub!( :alive? ).and_return( true ) controller.should_receive( :do_stuff ) do_get end How do I run the view first without Thing, If you're using mock_model and the constant Thing, then you have to create Thing to get that example to run. Admittedly, having to create that model class is a distraction from the flow, but it is a very small distraction that has never really bothered me that much. I imagine that we could tweak mock_model to accept a String, or perhaps somebody with stronger TextMate chops than mine could submit a patch to the TextMate bundle that would let you click on Thing and create a Thing model. and also keep track of alive? being decalred on the Thing instance? This is something that has come up on this list and in RFEs a few times. The most promising idea is to have a command line switch that would look at any mock that was passed a class name and ensure that the class responds to any mocked or stubbed methods. But even that would fall apart as soon as you start using any metaprogramming techniques to change the nature of an object at runtime. David, Is it not possible to check if a mocked model actually responds to a method call at the point of it being called? Then capture any that aren't on the original object and print out warnings similar to the pending notices? Please excuse my ignorance. I'm sure I've oversimplified this dramatically. Actually, that doesn't sound ignorant at all. I was thinking about it differently. Wanna take a crack at a patch? Here's the relevant RFE: http://rubyforge.org/tracker/index.php?func=detailaid=5064group_id=797atid=3152 Sure I'll try. I am not at all familiar with Rspec internals though. This is specific to the mocking framework, and should work for any application (rails or not), so you should be able to just focus on that part of the system. ;) -Daniel For me, the answer to keeping track of mocked methods is automated end-to-end tests. Either in browser, or something like Rails' integration tests (assuming Rails), or (soon) rbehave's story runner (which is now being integrated into rspec
Re: [rspec-users] Stubbing Observers in rails?
On 7/30/07, Doug Cole [EMAIL PROTECTED] wrote: In most of my tests I'd like to be able to stub out the observers for my models, but I'm not sure the best way to do this. I doesn't look like there is a way to stub all instance methods, and I don't seem to be able to stub early enough to stub out the observer as it's instantiated. I can think of several hackish ways to get around it, but I was wondering if anyone could suggest a good solution? Thanks! If you're looking to stub all instances, why not use (what) Rails (calls) mocks? ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] helper spec not finding rails core helpers
On 7/30/07, linojon [EMAIL PROTECTED] wrote: Hi, My helper specs were going ok until I added a call to a rails DateHelper method in one of my helpers http://api.rubyonrails.com/classes/ActionView/Helpers/ DateHelper.html#M000574 The helper runs fine from my view templates, just dies in the spec test. I boiled my question down to a simple (not too useful) example. I'm not sure what I'm missing. # application_helper.rb module ApplicationHelper def app_foo t = Time.now distance_of_time_in_words( t, t + 50.minutes) return true end end # application_helper_spec.rb require File.dirname(__FILE__) + '/../spec_helper' describe ApplicationHelper do it should find app_foo in application_helpers.rb do app_foo.should be_true end end # error output NoMethodError in 'ApplicationHelper should find app_foo in application_helpers.rb' undefined method `distance_of_time_in_words' for [Dynamically generated class for RSpec example]:#Class:0x32d11c8 Please put bug reports, feature requests, and patches here: http://rubyforge.org/tracker/index.php?group_id=797 ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] helper spec not finding rails core helpers
On 7/31/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, linojon [EMAIL PROTECTED] wrote: Hi, My helper specs were going ok until I added a call to a rails DateHelper method in one of my helpers http://api.rubyonrails.com/classes/ActionView/Helpers/ DateHelper.html#M000574 The helper runs fine from my view templates, just dies in the spec test. I boiled my question down to a simple (not too useful) example. I'm not sure what I'm missing. # application_helper.rb module ApplicationHelper def app_foo t = Time.now distance_of_time_in_words( t, t + 50.minutes) return true end end # application_helper_spec.rb require File.dirname(__FILE__) + '/../spec_helper' describe ApplicationHelper do it should find app_foo in application_helpers.rb do app_foo.should be_true end end # error output NoMethodError in 'ApplicationHelper should find app_foo in application_helpers.rb' undefined method `distance_of_time_in_words' for [Dynamically generated class for RSpec example]:#Class:0x32d11c8 Please put bug reports, feature requests, and patches here: http://rubyforge.org/tracker/index.php?group_id=797 I went ahead and entered and fixed this: http://rubyforge.org/tracker/index.php?func=detailaid=12714group_id=797atid=3149 Please do report bugs to the tracker, however. I am not always able to jump on things I see on this list. Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Stubbing Observers in rails?
On 7/31/07, Doug Cole [EMAIL PROTECTED] wrote: If I'm not mistaken those stub them out always - I'd like to be able to stub them out for most tests, but I would like to have them around when I want to write tests for the observers themselves! I imagine this is a fairly common use case for Observers and testing. There's an RFE for stubbing all instances: http://rubyforge.org/tracker/?func=detailgroup_id=797aid=6791atid=3152 It's been there for a while. This is very low priority for me, so if you're interested in seeing it happen your best bet would be to submit a patch. Alternatively, I *think* that mocha supports this, so you could use mocha with RSpec instead of the rspec mock framework. Cheers, David If you're looking to stub all instances, why not use (what) Rails (calls) mocks? ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] upgrading from CURRENT to trunk
On 7/31/07, Jonathan Linowes [EMAIL PROTECTED] wrote: I've been on CURRENT I tried to switch to trunk but its not completing. How do I install the trunk version? (for rails) (I apologize in advance for being clueless) Here's my steps: First, I brought everything I have up to date: $ sudo gem update ZenTest $ sudo gem update rspec $ script/plugin update rspec $ script/plugin update rspec_on_rails and realized I'm on CURRENT, so I then did: $ rm -rf vendor/plugins/rspec $ rm -rf vendor/plugins/rspec_on_rails $ script/plugin install svn://rubyforge.org/var/svn/rspec/trunk rspec_trunk Try this: script/plugin install svn://rubyforge.org/var/svn/rspec/trunk rspec ... Plugin not found: [svn://rubyforge.org/var/svn/rspec/trunk, rspec_trunk] Unsure about that error, I then tried to build it $ cd vendor/plugins/rspec $ rake kept getting errors about missing gems, installed the gems and rake'd again until it told me to run: $ rake install_dependencies which does a bunch of stuff and then actually installs rails/1.2.2 under vendor/plugins/rspec/example_rails_app/vendor/rails/1.2.2/ and then also installs 1.2.3 ... and then also edge... UGH!! I stopped it before it finished, as i really dont want/need the sample app and rails versions ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] upgrading from CURRENT to trunk
On 7/31/07, Robby Russell [EMAIL PROTECTED] wrote: David Chelimsky wrote: On 7/31/07, Jonathan Linowes [EMAIL PROTECTED] wrote: I've been on CURRENT I tried to switch to trunk but its not completing. How do I install the trunk version? (for rails) (I apologize in advance for being clueless) Here's my steps: First, I brought everything I have up to date: $ sudo gem update ZenTest $ sudo gem update rspec $ script/plugin update rspec $ script/plugin update rspec_on_rails and realized I'm on CURRENT, so I then did: $ rm -rf vendor/plugins/rspec $ rm -rf vendor/plugins/rspec_on_rails $ script/plugin install svn://rubyforge.org/var/svn/rspec/trunk rspec_trunk Try this: script/plugin install svn://rubyforge.org/var/svn/rspec/trunk rspec Might I take this opportunity to encourage you all to consider using piston for managing external dependencies within your repository. :-) Hear, hear! http://piston.rubyforge.org/ http://rubyurl.com/qZi (article on using it) Cheers, Robby -- Robby Russell http://www.robbyonrails.com # my blog http://www.planetargon.com # my business http://www.programmingrails.com # my book ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Unimplemented Spec idea
On 7/31/07, Daniel N [EMAIL PROTECTED] wrote: On 8/1/07, Scott Taylor [EMAIL PROTECTED] wrote: I absolutely love the unimplemented spec idea, and tend to use it a lot. But occasionally it gets in my way, when I rush to write a spec, and then want to change it to a non-implemented spec. My normal solution is to comment out the do...end block. Is there a better way? Stealing an idea from Dan North, how about something like this: it should do such and such, :pending = true do # unimplemented spec goes here end To make the spec run, simply remove the :pending key. I'm sure this would be rather trivial to implement as well. Thoughts? Scott This is already included. At least it is in edge. You call the pending( some reason ) method at the top of your example to do this. it should do stuff do pending( Don't run this yet ) # specs go here for unimplemented feature end You can also do this: it should not do this buggy thing do pending awaiting bug fix do # buggy code end end When the code in the block fails, the example shows up as pending. When it passes, it shows up as a failure, saying that the failure was expected but it passed instead. HTH Daniel ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] installing trunk (was: upgrading from CURRENT to trunk)
On 7/31/07, Jonathan Linowes [EMAIL PROTECTED] wrote: Hi, I must be missing something obvious. $ rm -rf vendor/plugins/rspec $ script/plugin install svn://rubyforge.org/var/svn/rspec/trunk rspec Exported revision 2188. Plugin not found: [svn://rubyforge.org/var/svn/rspec/trunk, rspec] $ ls vendor/plugins rspec/ (etc) $ ls vendor/plugins/rspec README Rakefile example_rails_app/ rspec/ spec_distributed/ RSpec.tmbundle/ doc/ pre_commit/ rspec_on_rails/ spec_ui/ but if i manually shuffle things around, then i'm ok: $ mv vendor/plugins/rspec ~/ $ mv ~/rspec/rspec vendor/plugins/ $ mv ~/rspec/rspec_on_rails vendor/plugins/ this works Probably a script or svn thing I'm doing wrong? Sorry - I typed it wrong. See http://rspec.rubyforge.org/documentation/rails/install.html. Instructions for trunk are further down the page. David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] :render expects possible?
On 8/1/07, Edward Ocampo-Gooding [EMAIL PROTECTED] wrote: Hi, Is it possible to do the following in a controller spec? @controller.should_receive(:render).with(:layout = false) I've been trying this kind of thing and it looks like RSpec is messing with the render calls, and requires you to use render_template instead. Could we have at least a warning that mentions that parameters passed to :render expectations are going to be thrown away and mention an alternative way of spec-ing this behaviour? In trunk, when you call should_receive(:render) you will get an error saying you should use the new method (also in trunk) controller.expects_render. Cheers, David Thanks, Edward ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] :render expects possible?
On 8/2/07, Edward Ocampo-Gooding [EMAIL PROTECTED] wrote: David Chelimsky wrote: On 8/1/07, Edward Ocampo-Gooding [EMAIL PROTECTED] wrote: Hi, Is it possible to do the following in a controller spec? @controller.should_receive(:render).with(:layout = false) I've been trying this kind of thing and it looks like RSpec is messing with the render calls, and requires you to use render_template instead. Could we have at least a warning that mentions that parameters passed to :render expectations are going to be thrown away and mention an alternative way of spec-ing this behaviour? In trunk, when you call should_receive(:render) you will get an error saying you should use the new method (also in trunk) controller.expects_render. Right on. Thanks for the tip. By the way, is there support for catching methods that haven't been stubbed out on mock objects and throwing appropriate warnings? Sorry but I don't really understand what you mean? Can you give an example? The last time this happened by accident, I just got a mess of rspec debugging log dumps. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Best practice integration testing
On 8/2/07, Hussein Morsy [EMAIL PROTECTED] wrote: We're working on getting the rbehave story runner merged into rspec and able to integrate w/ rails, but that's probably a couple of months away from reality. nice to hear :-) Right now I just use rails integration testing and spec/ui to drive in-browser tests with Selenium or Watir. To you have an example how to use spec/ui ? There are examples in the spec/ui directory tree: svn co svn://rubyforge.org/var/svn/rspec/trunk/spec_ui Chears Hussein ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] got/expects causes mental layering violation
On 8/2/07, Jay Levitt [EMAIL PROTECTED] wrote: I was, for the first time, spec'ing a class that redefined ==. And my spec was incorrect, so == was returning false. The result was something like: class C def ==(other) false end end .. C.new.should == other... expected other, got #C:0x7f03c454 (using ==) What did it really call other? The output should be evaluating a variable there, not naming it. But wait! Why on earth is == returning the class itself instead of true/false? That shouldn't be possible. No, no time for coffee, let me go debug this for a few hours... oh. of course. == IS returning a boolean value, in this case, false; rspec is helpfully showing me C.inspect so I can see why they MIGHT differ, assuming I haven't redefined ==. Which I have. Would it be good, when == is redefined (or eql? or equals?) for the rspec output to indicate somehow what it's doing and why you might be seeing what you're seeing? Maybe something like expected C==other, but C!=other. You have redefined ==. C.inspect shows: #C:... but much prettier and better worded. Or do I just call this a learning experience? I must be missing something. I don't really understand the problem you are experiencing. Any class can redefine == at any time. Many library classes do. That's just part of the language. You defined == to always return false, so the feedback you got seems to be the feedback you would expect. Even if you do explain this differently and I end up seeing it differently, I don't think it's feasible for rspec to be trying to discover what methods get defined, overridden, etc, and when. Cheers, David Jay ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Do the :attributes and :content matchers work
On 8/2/07, sinclair bain [EMAIL PROTECTED] wrote:
[Rails plugin 1.0.5]
Hi,
I am looking for some guidance.
When working on a partial which looks like this
div class=bug style=width: 100%; /
I have some examples which should fail - I think - but do not:
it ' should fail' do
response.should have_tag( 'div.bug', :content = 'There is no
content!' )
end
it ' should fail since there is no bug attribute with a value of
here' do
response.should have_tag( 'div', :attributes = {:bug = here} )
response.should have_tag( 'div', :attributes = {:bug = here,
:another_bug = 'there'} )
end
I am calling render :partial = '/bug/div' in the before :each block.
As I said I would expect this to fail but it does not.
I am trying this because in the
my_app/vendor/plugins/rspec_on_rails/spec/rails/dsl/view_spec_spec.rb
file there is an example
describe A view that includes a partial using :collection and
:spacer_template, :behaviour_type = :view do
before(:each) do
render
view_spec/partial_collection_including_template
end
it should render the partial w/ spacer_tamplate do
response.should have_tag('div', :content = 'Alice')
response.should have_tag('hr', :attributes ={:id = spacer})
response.should have_tag('div', :content = 'Bob')
end
Ugh. Those are holdovers from the old API and are only passing because
:content and :attributes are being ignored. I'm updating them in rspec
trunk to correctly reflect the API.
end
which does just this.
Can anyone help please ?
Cheers!
sinclair
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] reusable specs - almost there
On 8/4/07, David Green [EMAIL PROTECTED] wrote: I have a lot of controllers with virtually identical functionality for most actions. I've been using shared behaviours to DRY things up a bit, but I still have to create separate behaviours for each context before I can use the shared behaviours what I have now is a generic file which contains all the behaviours and examples common to all the controllers, and that file gets loaded from an actual controller spec. The generic file knows which controller to test by calling kontroller(), which is defined in the controller spec. here's a very simplified example: http://pastebin.com/m6b47bae9 It works great when I run the specs individually, but when I use rake, specs begin to fail and i think it's because the value of kontroller() is set to whatever it returns the first time it gets called. Here's the rake output from running the specs shown above: FooController .FooController . Finished in 0.041793 seconds 2 examples, 0 failures I would expect it to print FooController and then BarController ... interestingly, if I insert 'puts kontroller.to_s' *outside* of the describe block, then it does output the names of both controllers as expected. does anyone know of a solution? thanks dave I'm all for keeping things DRY, but NEVER at the risk of clarity. You've got to balance DRY and readability/clarity. Anybody familiar with rspec can look at this: = describe FooController do it_should_behave_like All Controllers end = and understand what that means: A FooController should behave like All Controllers. Perhaps there is a split second of mental mapping: Oh, there must be some behaviour described for all controllers that the FooController should adopt. Compare that to your example: = def kontroller FooController end load File.dirname(__FILE__) + '/all_controllers.rb' = First of all - how is that any more DRY than the example above? Perhaps you save a few keystrokes, but if you think that makes it more DRY then you don't really understand what DRY is all about. Second of all, what does it actually mean? Where's the story? How is a non-developer going to look at that and have any context for what that means? I'm a developer and I don't know what it means. Sure I can figure it out, but, in my opinion, it's just nowhere near as clear as the example above. FWIW, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] pending w/ no string
On 8/6/07, Scott Taylor [EMAIL PROTECTED] wrote: Is there some reason that pending() *MUST* take an argument? There was no discussion of this when the feature was contributed. Thinking about it now, to allow for no arg would require good default messages - one for when there is a block and one for when there is not. As long as you can come up w/ messages that really make sense in all situations, then a patch would be welcome. Scott ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] pending w/ no string
On 8/6/07, Scott Taylor [EMAIL PROTECTED] wrote: On Aug 6, 2007, at 7:19 AM, David Chelimsky wrote: On 8/6/07, Scott Taylor [EMAIL PROTECTED] wrote: Is there some reason that pending() *MUST* take an argument? There was no discussion of this when the feature was contributed. Thinking about it now, to allow for no arg would require good default messages - one for when there is a block and one for when there is not. As long as you can come up w/ messages that really make sense in all situations, then a patch would be welcome. How about accepting no arguments if no block is given? I think that would be more confusing - it should work the same way for both situations. Scott ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problems with array mock
On 8/6/07, aslak hellesoy [EMAIL PROTECTED] wrote: @curr_odontogram.photos.should_receive(:[]).with(1).and_return(@photo) Aslak D'oh! Of course - that should do it. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] used the described Class in a shared behavior
On 8/6/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is it possible to access the described class in a shared behavior? I'm trying to do something like this: describe Siberian feline, :shared = true do described_class_instance_as :feline, :name = fluffy, :breed = Siberian # or maybe before(:all) do @feline = described_class.new(:name = fluffy, :breed = Siberian) end it should have long hair do @feline.should be_long_haired end end describe SiberianCat, (a subclass of, say, Cat) do it_should_behave_like Siberian feline it should purr do @feline.sound.should == purr end end describe SiberianTiger, (a subclass of BigCat) do it_should_behave_like Siberian feline it should roar do @feline.sound.should == roar end end I'm looking for something more elegant than my current way, which is like so: describe Siberian felines, :shared = true do before(:all) do @feline = @klass.new(:name = fluffy, :breed = Siberian) end it should have long hair do @feline.should be_long_haired end end describe SiberianCat, (a subclass of, say, Cat) do it_should_behave_like Siberian felines before(:all) do @klass = SiberianCat end it should purr do @feline.sound.should == purr end end describe SiberianTiger, (a subclass of BigCat) do it_should_behave_like Siberian felines before(:all) do @klass = SiberanTiger end it should roar do @feline.sound.should == roar end end The way you're approaching it means that if something changes about the initializer for the SiberianTiger that doesn't change for the initializer of the SiberianCat, you're kinda screwed. I'd do it like this: http://pastie.caboo.se/85444 This keeps the shared behaviour very simple (all it needs is an instance variable) and puts control of the object you're dealing with in the spec. WDYT? Also - side note - before(:each) is preferred over before(:all) because it's better to be sure that each example starts with a clean slate. If one should change the state of the object you're describing, you could end up with unexpected results and hair-pulling debugging sessions. Then again, i have a gut feeling that if i took better advantage of modules it wouldn't be an issue... -Ben ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Rspec controller test
On 8/7/07, Shaker [EMAIL PROTECTED] wrote: Great Hi to everybody! I am currently working on a project which tests the controllers using rspec. I came across some methods in the controller which do not generate any actions at all. However, they still need testing! Some of these methods do require parameters. I am wondering how I can pass the test cases as the parameters to these targeted methods in the controller spec?? Below is a simple example for illustration: in the controller: def method_for_test(parameter_1, parameter_2) #do some coding #no action end in the controller_spec: it should test the method_for_test do parameter_1 parameter_2 ??how to pass them to method_for_test end controller.method_for_test(arg1, arg2) Thank you all in advance. -- View this message in context: http://www.nabble.com/Rspec-controller-test-tf4229016.html#a12030820 Sent from the rspec-users mailing list archive at Nabble.com. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problems with raising errors on a mocked object
On 8/7/07, Eivind Uggedal [EMAIL PROTECTED] wrote: I'm trying to mock a object to raise a certain error. By doing so I get a ArgumentError on ActiveRecord's save! method: http://pastie.caboo.se/85628 I've tried to debug it but just can't seem to find what I'm doing wrong. Any help is greatly appreciated. Please run this: ruby script/spec ./spec/controllers/users_controller_spec.rb -b That will give the complete backtrace for the failure, which I'd ask you to pastie as well. Cheers, Eivind Uggedal ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Failed to pass arguments to controller method
On 8/7/07, Shaker [EMAIL PROTECTED] wrote: Good morning to everyone: So weird!! I got a method called apply_settings(arg1, arg2) in the controller to be tested. In the controller spec, I of course called the method. In the controller: def apply_settings(arg1, arg2) #where arg1 is a hash, and arg2 is an array of object #do some coding end In the controller spec: before(:each) do @controller = Controller.new end it should test the apply_settings do @controller.apply_settings(Hash.new, array_of_object) #where the arguments are exactly some format #as required end However, it yielded wrong number of arguments(0 for 1) error after I ran the spec. It there anything wrong in my spec? Difficult to say with the little bit of code you're posting. It would be a lot easier to help if you posted the full code of the spec'd method, the spec, and the resulting backtrace. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problems with raising errors on a mocked object
On 8/8/07, Eivind Uggedal [EMAIL PROTECTED] wrote: Here you go: http://pastie.caboo.se/85876 OK - that helped. The and_raise method can take an exception class or object. If you pass it the class, it will try to create an instance of it using Klass.new. This is the source of the problem. In your example we see: @user.should_receive(:save!).and_raise(ActiveRecord::RecordInvalid) Rspec tries to call ActiveRecord::RecordInvalid.new, but that requires an argument, which is why you get an error saying it got 0 for 1 arguments. Because and_raise can also take an exception object, the solution to this problem is: @user.should_receive(:save!).and_raise(ActiveRecord::RecordInvalid.new(@user)) I guess the root of the problem is poor docs - I'm updating the rdoc now and it will be published with the next release. Cheers, David Eivind On 8/8/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/7/07, Eivind Uggedal [EMAIL PROTECTED] wrote: I'm trying to mock a object to raise a certain error. By doing so I get a ArgumentError on ActiveRecord's save! method: http://pastie.caboo.se/85628 I've tried to debug it but just can't seem to find what I'm doing wrong. Any help is greatly appreciated. Please run this: ruby script/spec ./spec/controllers/users_controller_spec.rb -b That will give the complete backtrace for the failure, which I'd ask you to pastie as well. Cheers, Eivind Uggedal ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problems with RESTfully generated helpers
On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote: I am using helper the RESTfully generated helper methods in my views. My routes are nested so the helpers appear to need arguments passed to them, but it works without arguments. Say for example I have pages and comments. If I do page_comments_path without parameters, it works. However, when I run the rspec test, it fails and tells me i'm missing parameters. I tried to pass params[:page_id], but it still says it needs parameters. I did fill in the parameters like it asked and the test passed, but I think my views look cleaner without the arguments being passed everywhere. Do I have to stub these methods to get my views to pass, or is there some other way? It would be much easier to answer your question if you posted the actual spec and code. TIA, Lance ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problems with RESTfully generated helpers
On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote:
I just passed label_artist_path(@label.id, @artist.id) into the view
and it worked.. but I really don't want to have to pass those
parameters in all my views. It looks ugly. Does anyone know a way
around this without stubbing? It seems useless to test this view
without allowing those methods to act out their real behavior.
Can you point me to docs that say you're supposed to be able to just
call label_artist_path without any args? I've not see such docs and I
can't get it to work in any of my views - and I'm talking about just
rendering the views at all, not getting specs to work.
-TIA
On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote:
ActionView::TemplateError in 'Edit Artist Page should render the edit
artist form'
label_artist_url failed to generate from {:controller=artists,
:action=show} - you may have ambiguous routes, or you may need to
supply additional parameters for this route. content_url has the
following required parameters: [labels, :label_id, artists, :id] -
are they all satisfied?
On line #3 of app/views/artists/edit.rhtml
1: h1Editing artist/h1
2:
3: % form_tag label_artist_path, :method = :put do %
4: %= render :partial = 'form' %
5: %= submit_tag 'Save' %
6: % end %
My spec looks like:
require File.dirname(__FILE__) + '/../../spec_helper'
describe 'Edit Artist Page' do
before do
@label = mock_model(Label)
@artist = mock_model(Artist)
assigns[:label] = @label
assigns[:artist] = @artist
end
def render_edit
render :template = 'artists/edit'
end
it should render the edit artist form do
render_edit
end
end
On 8/8/07, David Chelimsky [EMAIL PROTECTED] wrote:
On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote:
I am using helper the RESTfully generated helper methods in my views.
My routes are nested so the helpers appear to need arguments passed to
them, but it works without arguments. Say for example I have pages and
comments. If I do page_comments_path without parameters, it works.
However, when I run the rspec test, it fails and tells me i'm missing
parameters. I tried to pass params[:page_id], but it still says it
needs parameters. I did fill in the parameters like it asked and the
test passed, but I think my views look cleaner without the arguments
being passed everywhere. Do I have to stub these methods to get my
views to pass, or is there some other way?
It would be much easier to answer your question if you posted the
actual spec and code.
TIA,
Lance
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problems with RESTfully generated helpers
On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote:
All I'm doing is passing the instance variables @label and @artist in
the controller to the view using this code:
@label = current_user.labels.find(params[:label_id])
@artist = params[:id].nil? ? Artist.new : @label.artists.find(params[:id])
By sending these two instance variables to the view, I don't need to
specify these arguments and the view just works. Can you get it to
work when you specify these instance variables in your controller?
No. That's what I'm saying. I get the same ambigous URL error you
cited in the first email in this thread, but in the browser. Using
edge rails, edge rspec.
-L
On 8/8/07, David Chelimsky [EMAIL PROTECTED] wrote:
On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote:
I just passed label_artist_path(@label.id, @artist.id) into the view
and it worked.. but I really don't want to have to pass those
parameters in all my views. It looks ugly. Does anyone know a way
around this without stubbing? It seems useless to test this view
without allowing those methods to act out their real behavior.
Can you point me to docs that say you're supposed to be able to just
call label_artist_path without any args? I've not see such docs and I
can't get it to work in any of my views - and I'm talking about just
rendering the views at all, not getting specs to work.
-TIA
On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote:
ActionView::TemplateError in 'Edit Artist Page should render the edit
artist form'
label_artist_url failed to generate from {:controller=artists,
:action=show} - you may have ambiguous routes, or you may need to
supply additional parameters for this route. content_url has the
following required parameters: [labels, :label_id, artists, :id] -
are they all satisfied?
On line #3 of app/views/artists/edit.rhtml
1: h1Editing artist/h1
2:
3: % form_tag label_artist_path, :method = :put do %
4: %= render :partial = 'form' %
5: %= submit_tag 'Save' %
6: % end %
My spec looks like:
require File.dirname(__FILE__) + '/../../spec_helper'
describe 'Edit Artist Page' do
before do
@label = mock_model(Label)
@artist = mock_model(Artist)
assigns[:label] = @label
assigns[:artist] = @artist
end
def render_edit
render :template = 'artists/edit'
end
it should render the edit artist form do
render_edit
end
end
On 8/8/07, David Chelimsky [EMAIL PROTECTED] wrote:
On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote:
I am using helper the RESTfully generated helper methods in my
views.
My routes are nested so the helpers appear to need arguments passed
to
them, but it works without arguments. Say for example I have pages
and
comments. If I do page_comments_path without parameters, it works.
However, when I run the rspec test, it fails and tells me i'm
missing
parameters. I tried to pass params[:page_id], but it still says it
needs parameters. I did fill in the parameters like it asked and the
test passed, but I think my views look cleaner without the arguments
being passed everywhere. Do I have to stub these methods to get my
views to pass, or is there some other way?
It would be much easier to answer your question if you posted the
actual spec and code.
TIA,
Lance
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] using RSpec's trunk in non-rails projects w/ Autotest
On 8/8/07, Scott Taylor [EMAIL PROTECTED] wrote: I was working on the same issue David was (to fix autotest to work for RSpec's trunk), only to find that David had modified it. Sorry - I saw the RFE and was taking a look at solutions and it was too easy to not just do. I have refactored the autotest plugin to use vendor/plugin/rspec/bin if that exists, and have spec'ed out most of the Autotest. This means that a non-rails project could use vendor/plugins w/ rspec checked out, and autotest should work out of the box. Right now spec coverage is at 99.7%, so I'm working on finishing up the specs for RSpec's autotest. (David, I assume this would be welcome?) Absolutely I'll stay out of your way on this one :) Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] using RSpec's trunk in non-rails projects w/ Autotest
On 8/8/07, Scott Taylor [EMAIL PROTECTED] wrote: On Aug 8, 2007, at 4:30 PM, David Chelimsky wrote: On 8/8/07, Scott Taylor [EMAIL PROTECTED] wrote: I was working on the same issue David was (to fix autotest to work for RSpec's trunk), only to find that David had modified it. Sorry - I saw the RFE and was taking a look at solutions and it was too easy to not just do. I have refactored the autotest plugin to use vendor/plugin/rspec/bin if that exists, and have spec'ed out most of the Autotest. This means that a non-rails project could use vendor/plugins w/ rspec checked out, and autotest should work out of the box. Right now spec coverage is at 99.7%, so I'm working on finishing up the specs for RSpec's autotest. (David, I assume this would be welcome?) Absolutely I'll stay out of your way on this one :) Unfortunately, the specs (for the rest of our Autotest plugin) are coupled with the original refactoring that I made. I hope that's alright (I've had this problem with multiple patch dependencies in the past). If that's not OK, then I'll submit them, and write some throw away specs for the version that is currently on trunk. I'm less worried about the implementation than I am about being able to easily apply your patch to the current trunk. As long as I can do that, it's fine. Scott ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can't seem to spec a ActiveRecord::RecordInvalid exception properly...
On 8/8/07, Fischer, Daniel [EMAIL PROTECTED] wrote:
1 def create
2 @user = User.new(params[:user])
3 @user.save!
4 self.current_user = @user
5 redirect_to user_path(@user)
6 flash[:notice] = Thanks for signing up!
7 rescue ActiveRecord::RecordInvalid
8 render :action = 'new'
9 end
Try this:
describe /users/create do
before(:each) do
User.stub!(:new).and_return(@user = mock_model(User))
end
it should redirect to show on successful save do
@user.should_receive(:save!)
post :create
response.should redirect_to(user_path(@user))
end
it should re-render new on failed save do
@user.should_receive(:save!).and_raise(ActiveRecord::RecordInvalid.new(@user))
post :create
response.should render_template('new')
end
end
Cheers,
David
I can't seem to properly spec this out. I am trying numerous things, the
latest one is this, which makes sense but it still fails...
it should re-render new on an invalid record exception do
post :create, :user = {:login = nil}
response.should render_template(:new)
end
should re-render new on an invalid record exception
expected new, got nil
Any help would be great, thanks!
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problems with RESTfully generated helpers
On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote: Awesome! Thank you! :) Don't thank me yet. I've spent some time trying to track this down and I've found my way into some methods in routing.rb that are dynamically generated (and so you can't )(*)(* read them to debug them quite so easily) that call the methods (in your case) label_id_value and id_value (being the artist id). I have no idea yet where those two methods get generated. Once I do, then we can stub them. Unfortunately I can't really spend any more time on this right now (though I'd love to solve it). In the mean time, you'll just have to use the parameters if you want the specs to work with the same code with which your app works. On 8/8/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote: I just visited the action in my browser and i don't get any errors. I am also running on edge rails as the application relies on ActiveResource. Can you show me the code you created? OK - I've created a small project and am able to reproduce the behaviour you're describing. I'll follow up when learn something. David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] RSpec book?
On 8/8/07, Ashley Moran [EMAIL PROTECTED] wrote: http://www.apress.com/book/bookDisplay.html?bID=10368 Came across this as a stub page browsing Amazon UK. This is good news! I'm surprised it hasn't been discussed on the list before. Was Chad keeping it a secret? I hope it will have plenty of BDD theory. I'm still waiting for that magic book I can give to someone and say here - read this, it tells you how to build software. I don't think this will be the one and only book to solve that problem, but you should know that Aslak and I are working on an RSpec/BDD book as well. There are still some things being worked out, which is why I haven't really been spouting about it yet, but you can expect to be hearing quite a bit about it within the next few weeks. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] RSpec book?
On 8/8/07, Ashley Moran [EMAIL PROTECTED] wrote: I'm still waiting for that magic book I can give to someone and say here - read this, it tells you how to build software. Have you read this one? http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445/ref=pd_bbs_sr_1/002-7438072-0005646?ie=UTF8s=booksqid=1186627780sr=8-1 It pre-dates the BDD discussion, but is packed with very relevant material. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problems with RESTfully generated helpers
On 8/9/07, Lance Carlson [EMAIL PROTECTED] wrote: Is it possible that rspec is not pulling the instance variables into the method because this method is being defined before instance variables in parameters are assigned to that method? I'm trying to hone down where the problem is popping up exactly. Any insight? Not really more than what I said earlier in this thread. On 8/9/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/9/07, Lance Carlson [EMAIL PROTECTED] wrote: Were you able to come up with any solutions? Nope. Anyone else? On 8/8/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote: Awesome! Thank you! :) Don't thank me yet. I've spent some time trying to track this down and I've found my way into some methods in routing.rb that are dynamically generated (and so you can't )(*)(* read them to debug them quite so easily) that call the methods (in your case) label_id_value and id_value (being the artist id). I have no idea yet where those two methods get generated. Once I do, then we can stub them. Unfortunately I can't really spend any more time on this right now (though I'd love to solve it). In the mean time, you'll just have to use the parameters if you want the specs to work with the same code with which your app works. On 8/8/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote: I just visited the action in my browser and i don't get any errors. I am also running on edge rails as the application relies on ActiveResource. Can you show me the code you created? OK - I've created a small project and am able to reproduce the behaviour you're describing. I'll follow up when learn something. David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problems with RESTfully generated helpers
On 8/9/07, Lance Carlson [EMAIL PROTECTED] wrote: About these methods requiring arguments? I thought you were able to reproduce the problems I was having and was also able to reproduce a working application with no arguments. That is correct. By default these methods should not require arguments to be passed as it is unnecessary noise in the code. I understand that, but that was news to me as of this thread. I spent a couple of hours banging my head against this and found the generated code I mentioned earlier in the thread. That's the only insight I have to offer at this point. Perhaps we can continue this discussion on IRC? #rspec? I'll pop in at one point this morning but I really don't have much in the way of cycles to spend on this right now. I'm happy to help point you in the right direction, but it's not very high on my priority list. In the mean time, now that we know this is a bug, would you kindly report it in the tracker? http://rubyforge.org/tracker/?atid=3149group_id=797func=browse What is your s/n? On 8/9/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/9/07, Lance Carlson [EMAIL PROTECTED] wrote: Is it possible that rspec is not pulling the instance variables into the method because this method is being defined before instance variables in parameters are assigned to that method? I'm trying to hone down where the problem is popping up exactly. Any insight? Not really more than what I said earlier in this thread. On 8/9/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/9/07, Lance Carlson [EMAIL PROTECTED] wrote: Were you able to come up with any solutions? Nope. Anyone else? On 8/8/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote: Awesome! Thank you! :) Don't thank me yet. I've spent some time trying to track this down and I've found my way into some methods in routing.rb that are dynamically generated (and so you can't )(*)(* read them to debug them quite so easily) that call the methods (in your case) label_id_value and id_value (being the artist id). I have no idea yet where those two methods get generated. Once I do, then we can stub them. Unfortunately I can't really spend any more time on this right now (though I'd love to solve it). In the mean time, you'll just have to use the parameters if you want the specs to work with the same code with which your app works. On 8/8/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/8/07, Lance Carlson [EMAIL PROTECTED] wrote: I just visited the action in my browser and i don't get any errors. I am also running on edge rails as the application relies on ActiveResource. Can you show me the code you created? OK - I've created a small project and am able to reproduce the behaviour you're describing. I'll follow up when learn something. David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] and_yield + instance_eval(block)
On 8/10/07, Scott Taylor [EMAIL PROTECTED] wrote:
On Aug 10, 2007, at 3:43 PM, David Chelimsky wrote:
On 8/7/07, Scott Taylor [EMAIL PROTECTED] wrote:
I have the following code, which yields instance eval's the block
given:
class Foo
def bar(blk)
instance_eval blk
end
def baz
yield
end
end
The effect of this is that self is reassigned:
Foo.new.bar do
# here, self is the instance of Foo
# created by new
end
Why not just do this, which is already a language construct?
Foo.new.instance_eval { ... }
Maybe a better example would be in place. Consider the following
from the Autotest plugin:
Autotest.add_discovery do
rspec if File.exist?('spec')
end
How would you go about testing this?
It's easy enough to test that Autotest receives the method
add_discovery. But how would you deal with the block?
OK - now I'm starting to see. Concrete examples are always helpful.
I guess there's no mocking framework right now that would solve that
for you. What spec do you *wish* you could write?
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can't get should redirect_to match to work
On 8/10/07, sbellware [EMAIL PROTECTED] wrote: Folks, I've posted to the simple example I'm working with as well as the spec code and results here: http://pastie.caboo.se/86750 I can't seem to get this to work. Any ideas? As of some time ago, response.should redirect_to should come after the action. So: it get foo do get 'foo' response.should redirect_to(:action = 'bar') end Thanks, Scott -- View this message in context: http://www.nabble.com/Can%27t-get-should-redirect_to-match-to-work-tf4251891.html#a12101072 Sent from the rspec-users mailing list archive at Nabble.com. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] template.expect_render
On 8/11/07, Jonathan Linowes [EMAIL PROTECTED] wrote: oops, my bad this works (asserts pass, and partial not called) template.expect_render(:partial = 'bar/foo') render /layouts/bar.html.erb so does this: template.stub_render(:partial = 'bar/foo') render /layouts/bar.html.erb neither case seems to try to render the partial Right - the difference is that stub_render won't complain if the partial is not rendered, so if what you mean to do is specify that it should be rendered, then you should use expects_render. On Aug 11, 2007, at 6:11 AM, Jonathan Linowes wrote: Hi, I'd like to stub out a partial call but not sure how. I tried something like this it should render partial foo do template.stub_render(bar/foo) render /layouts/bar.html.erb response.should render(bar/foo) end but the partial is still getting called On Jun 27, 2007, at 1:31 AM, David Chelimsky wrote: Trunksters, I just added a couple of methods to ActionView::Base in Spec::Rails (as of r2136) that lets you do this in view examples: describe '/things/index.html.erb' do it should render _thing with a collection of things do assigns[:things] = things = [Object.new] template.expect_render(:partial = 'thing', :collection = things) render '/things/index.html.erb' end end This solves two big problems - mocking nested partials and mocking :object and :collection in partials. template.expect_render wraps part of 'spec/mocks', but not the whole framework - so we get the expectation matching benefit w/o conflicting with other mock frameworks that ppl might choose to use. There is also template.stub_render(opts) in case you just want to stub the render w/o verification. I would LOVE it if some of you would try this method out and provide feedback before we release it. Please feel to ask any questions about this on this list. Thanks, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] stubbing a method that yeilds sequential results
On 8/12/07, rupert [EMAIL PROTECTED] wrote:
I've just found myself stuck trying to rspec something so am hoping
someone more knowledgable can help.
I have a Connector class which has a class method 'results' that
yields results it get from a network service based on a set of
attributes that I pass to it. I am wanting to yield these results
from my Intermediate class up to the next 'level' so the basic no
frills set up would be this:
class Intermediate
def self.results(attributes)
Connector.each_result(attributes) do |result|
yield result
end
end
end
I've worked out how to stub things for the case where the Connector.
each_result method yields a result once
#setup
@result = mock(result)
Connector.stub!(:each_result).and_yield(@result)
@attributes = {}
@results = []
@block = Proc.new { |r| @results r }
#action
Intermediate.search_results(@attributes, @block)
# expectation
@results.should == [EMAIL PROTECTED]
However, what I actually need to do is check each result that is
yielded by the Connector.each_result method and compare it to the
previous one. If they are sufficiently similar I need to merge them
(and same again if the next result is sufficiently similar). I only
want to yeild merged results and results that are not similar to
their preceeding result(s) - I'd imagined he code to do this would be
something along the lines of:
class Intermediate
def self.results(attributes)
@saved_result = nil
Connector.each_result(attributes) do |result|
if results_match(result, @saved_result)
@saved_result.merge!(result)
else
yield @saved_result unless @saved_result.nil?
@saved_result = result
end
end
yield @saved_result unless @saved_result.nil?
end
def results_match(this, last)
return false if last.nil?
end
end
I can't for the life of me see how I should spec this though, as trying:
Connector.stub!(:results).and_yield(@result1, @result2)
is expecting the two results to be yielded at the same time and not
sequentially.
I'm pretty sure you can get what you want by using should_receive
instead of stub and doing this:
Connector.should_receive(:results).and_yield(@result1)
Connector.should_receive(:results).and_yield(@result2)
I can't see how to stub a method to yield sequential
results so I can spec the behavior for different scenarios of
similarities between subsequent results. Is it possible to do this?
Any help would be much appreciated
Cheers
Rupert
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] 1.0.6 gotcha
Hi All - I released 1.0.6 this morning, but there is apparently a bug related to rspec and autotest. I'll be fixing this today (but not until tonight) so you have two options: Wait until 1.0.7 (tonight) Upgrade now to 1.0.6 but make sure you install the rspec gem. Thanks, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] expect_render, why does there need to be a warning
On 8/14/07, Zach Dennis [EMAIL PROTECTED] wrote: On 8/14/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/14/07, Zach Dennis [EMAIL PROTECTED] wrote: There is a warning on the web site about expect_render and stub_render: WARNING: expect_render and stub_render, while very useful, act differently from standard Message Expectations (a.k.a. mock expectations), which would never pass calls through to the real object. This can be very confusing when there are failures if you're not aware of this fact, because some calls will be passed through while others will not. This is especially confusing when you use stub_render because, as with all Method Stubs, you will get very little feedback about what is going on. My questions: Is this a sign that expect_render is doing to much? Is there a benefit from having expect_render and stub_render sometimes pass the render call to the underlying template object? Why not force all partials to be tested individually? Testing partials individually seems like a cleaner, more consistent and less confusing route to go, especially when you consider the nesting of paritals which render other partials. That's the whole reason for the existence of expect_render. If you're spec'ing '_outer_partial' and you want to specify that it renders '_inner_partial', but you don't want to actually render '_inner_partial', there is no way to do that with traditional mocking frameworks because they are not designed to pay attention to one call to a method: render(:partial = '_inner_partial') while letting another call to the same method: render(:partial = '_outer_partial') through to the object. Agreed that expect_partial is doing to much, but what alternatives do we have? When testing views the first call to render is going to be the one that should be passed to the underlying template, since this is from the test. Every subsequent call to render will be done from within the template, so RSpec can look for a matching expectation. It seems that expect_render is in charge of setting those up. If this is done then a simple convention will be enforced, every inline render :partial call will have to be expected in a view spec, and every view template (or partial) will have to have it's own view test. This gets rid of issues of nesting, confusion and poorly written specs where someone is asserting contents of a partial rendered multiple levels deep in the render chain. Granted you end up with more view tests, but they are cleaner, shorter and easier to read. More importantly they are easier to maintain and update because they will be easy to find an existing spec for to start test driving changes, rather then having to find the view which renders your partial and the spec that renders that view (and heaven forbid your partial is used in several views, and each view tests the contents of that partial). I think you are describing a good convention, but I don't think rspec should force it on everybody. The goal here is to provide tools that ALLOW you to do things in certain ways but not force you to. For example, rspec_on_rails supports isolated views, but you can do rails-style functional tests (using controller specs with integrated views) if you want. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] nuby: how spec redirect_to at ApplicationController
On 8/15/07, Courtenay [EMAIL PROTECTED] wrote: On 8/15/07, Priit Tamboom [EMAIL PROTECTED] wrote: describe ApplicationController do it method login_required should redirect to home path without login do heh. it is so out of place here :) I agree. The goal is to describe behaviours of objects, not methods. So, I'd write: it should redirect anonymous user to home path Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] RSpec --format --html:/path/to/file.html
On 8/17/07, Cody P. Skidmore [EMAIL PROTECTED] wrote: Greetings everyone. I'm learning RSpec and am pretty fresh to Ruby/Rails, but am so excited I can't help jumping in. I'm running before I can walk here. :-) Yesterday I tried outputting test results to HTML instead of colorized plain text. It looked like there were some entries in the change log for the 1.0.5 release allowing RSpec to do what I wanted. I tried adding a setting to spec.opts but it didn't work to say the least. Here's the change log entry: * The --out option is gone. Use --format html:path/to/my.html instead (or similar). 1. Does this do what I think it should? In spec.opts, each line represents one command line arg, so you'd have to do this (on two separate lines): --format html:/path/to/my.html Then on the command line: spec spec -O path/to/spec.opts 2. where can I find documentation on using spec.opts? The command line help doesn't mention a --format option. Look at http://rspec.rubyforge.org/documentation/tools/spec.html. If you scroll down you'll see the output from the spec command. It definitely mentions the --format option. It looks like CI::Reporter [could] output XML format but can it be used independently? I'm mining the documentation for related information but didn't find it so far. Thank you for your help in advance. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Render template not matching absolute path
On 8/21/07, Ashley Moran [EMAIL PROTECTED] wrote:
Hi
I have a simple controller method like this:
class StylesheetsController ApplicationController
layout nil
session :off
def gap
site = Site.find_by_hostname(request.host)
@colours = site.colours
respond_to do |accepts|
accepts.css { render :file = #{RAILS_ROOT}/app/views/
stylesheets/gap.rcss }
end
end
end
And I want to test that it renders the gap.rcss file, but my spec,
it should render the gap.rcss template do
do_get
response.should render_template(gap.rcss)
end
fails with this error:
Expected gap.rcss, got /Users/ashleymoran/Documents/Development/
YourMoney/trunk/src/config/../app/views/stylesheets/gap.rcss
I don't remember this failing in 1.0.5, but it's been a while since I
worked on this project so might be just be my bad memory. Am I doing
something wrong or can you not spec render :file with render_template?
This changed in 1.0.0, but not since.
Take a look at render_template.rb. render_template supports either a
file name, in which case it prepends the controller-based path (i.e.
if the controller is 'foo' and you say 'bar', it will match
'foo/bar'), or a path. In either case it matches against
response.rendered_file - it does not do any real path resolution -
it's just matching strings.
HTH,
David
Thanks
Ashley
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] testing behaviour or testing code?
On 8/24/07, Pat Maddox [EMAIL PROTECTED] wrote: On 8/24/07, David Chelimsky [EMAIL PROTECTED] wrote: describe Widget, class do it should provide a list of widgets sorted alphabetically do Widget.should_receive(:find).with(:order = name ASC) Widget.find_alphabetically end end You're correct that the refactoring requires you to change the object-level examples, and that is something that would be nice to avoid. But also keep in mind that in java and C# people refactor things like that all the time without batting an eye, because the tools make it a one-step activity. Refactoring is changing the design of your *system* without changing its behaviour. That doesn't really fly all the way down to the object level 100% of the time. WDYT? I think that example is fine up until the model spec. The find_alphabetically example should hit the db, imo. With the current spec there's no way to know whether find_alphabetically actually works or not. You're relying on knowledge of ActiveRecord here, trusting that the arguments to find are correct. Au contrare! This all starts with an Integration Test. I didn't post the code but I did mention it. What I've found when I write specs is that I discover new layers of services until eventually I get to a layer that actually does something. When I get there, it's important to have specs that describe what it does, not how it does it. In the case of find_alphabetically we care that it returns the items in alphabetical order. Not that it makes a certain call to the db. I play this both ways and haven't come to a preference, but I'm leaning towards blocking database access from the rspec examples and only allowing it my end to end tests (using Rails Integration Tests or - soon - RSpec's new Story Runner). Pat ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] testing behaviour or testing code?
On 8/24/07, Pat Maddox [EMAIL PROTECTED] wrote: On 8/24/07, David Chelimsky [EMAIL PROTECTED] wrote: On 8/24/07, Pat Maddox [EMAIL PROTECTED] wrote: On 8/24/07, David Chelimsky [EMAIL PROTECTED] wrote: describe Widget, class do it should provide a list of widgets sorted alphabetically do Widget.should_receive(:find).with(:order = name ASC) Widget.find_alphabetically end end You're correct that the refactoring requires you to change the object-level examples, and that is something that would be nice to avoid. But also keep in mind that in java and C# people refactor things like that all the time without batting an eye, because the tools make it a one-step activity. Refactoring is changing the design of your *system* without changing its behaviour. That doesn't really fly all the way down to the object level 100% of the time. WDYT? I think that example is fine up until the model spec. The find_alphabetically example should hit the db, imo. With the current spec there's no way to know whether find_alphabetically actually works or not. You're relying on knowledge of ActiveRecord here, trusting that the arguments to find are correct. Au contrare! This all starts with an Integration Test. I didn't post the code but I did mention it. You're absolutely right, there should be an integration or acceptance test that exercises the behavior. I would question then whether or not the example for find_alphabetically is (a) pulling its weight or (b) too brittle. (a) What value does the example provide? It doesn't serve to document how find_alphabetically is used (usage doco is provided by good naming, and secondarily by the controller specs). It doesn't give you any information that you couldn't get by looking at the implementation, because it duplicates the implementation exactly. So the only real benefits of it is that you can see it when you visually scan the specs, and it shows up in the output when you generate spec docs. Those are real benefits, of course, which leads me to believe that the spec is just a bit brittle. Knowing what exact arguments are passed to Widget.find doesn't add any value. It makes the test more cluttered and brittle. All we really care about is that a find is performed. In that case, perhaps the example should be simply it should provide a list of widgets sorted alphabetically do Widget.should_receive(:find) Widget.find_alphabetically end WDYT? The problem w/ that, for me, is that if I change that method for any reason I won't know if I broke anything until I run the integration tests. I'll trade off a bit of brittleness for rapid feedback. Not always - but usually. I play this both ways and haven't come to a preference, but I'm leaning towards blocking database access from the rspec examples and only allowing it my end to end tests (using Rails Integration Tests or - soon - RSpec's new Story Runner). Will Story Runner give us all the same abilities as Rails ITs, obviating the need for test::unit altogether? Yes. Just need to figure out how to wrap IT w/ Story Runner. Cheers, David Pat ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Spec'ing ApplicationController
On 8/14/07, sbellware [EMAIL PROTECTED] wrote: Folks, I'd like to spec the behaviors that I'm adding to ApplicationController. Specifically, I'm adding: def authenticated? session[:username] != nil end I described ApplicationController, but couldn't figure out how to call the authenticated method. I'm probably going about this quite wrongly and would appreciate any hints? The way I handle this is with a shared behaviour that includes specs for behaviours inherited from ApplicationController, but I run them against the real controllers. Thanks, Scott -- View this message in context: http://www.nabble.com/Spec%27ing-ApplicationController-tf4270301.html#a12154175 Sent from the rspec-users mailing list archive at Nabble.com. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can module spec behave like controller spec?
On 8/31/07, Shaker [EMAIL PROTECTED] wrote: Hello everyone: Right now I am writing spec on modules, which are provided by my colleagues. Some of the modules actually contain action methods. I tried very hard to spec those action methods in modules. But it seems that the rspec does not allow module spec to 'get' action like controller does. After I saw the documentation, I then used :behaviour_type=:controller. However, it failed again. It reported an error for me. For illustration, I'd like a simple example. module MyModule def copy #an action method render :partial=/index, :layout=false end end describe MyModule, :behaviour_type=:controller do it should render partial index do get 'copy' #test code not provided yet, just want to get the action end end The error reported was: undefined method 'new' for MyModule:Module. Do you guys have any idea of the error? And how should I test the action methods in modules? The ControllerBehaviour is trying to instantiate MyModule. What you'd need to do is something like this: class ControllerThatUsesMyModule include MyModule end describe ControllerThatUsesMyModule, :behaviour_type=:controller do it should render partial index do get 'copy' #test code not provided yet, just want to get the action end end I haven't tried it, but it seems like it should work. Give it a whirl and report back please. Cheers, David Cheers! -- View this message in context: http://www.nabble.com/Can-module-spec-%22behave-like%22-controller-spec--tf4358891.html#a12422548 Sent from the rspec-users mailing list archive at Nabble.com. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Setting use_transactional_fixtures=false for a single spec - a bad idea?
On 8/31/07, Peter Marklund [EMAIL PROTECTED] wrote: Hi! I would really like to find a way to allow me to write RSpec specifications for code that use database transactions. I know I can set config.use_transactional_fixtures = false in my spec_helper.rb. That works, and that's great, but it will (I think) slow down my specs quite a bit. I would like to turn off transactional fixtures for just a single spec (describe), or even better, just a single example (it). I tried this: before(:all) do Spec::Runner.configure do |config| config.use_transactional_fixtures = false end end after(:all) do Spec::Runner.configure do |config| config.use_transactional_fixtures = true end end but that didn't work. Or is setting use_transactional_fixtures=false on a global level really the way to go even if it slows you down? It certainly feels a lot cleaner and solid to me. Maybe I need more db stubbing. Thanks in advance for any pointers! I'd set up a separate folder for these specs and tweak the rake tasks to run those specs in a separate process, w/ its own spec_helper that sets config.use_transactional_fixtures to false. Cheers Peter http://marklunds.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] How to spec routes for a resource nested in multiples resources?
On 8/31/07, Edgar Gonzalez [EMAIL PROTECTED] wrote: Hi, I got the resource Llamadas nested in: - Operadores - Productos - Centros Here is part of my routes http://pastie.caboo.se/92767 I want to spec that the routes for Llamadas, I tried several approachs: - route_for(:controller = llamadas, :action = exitosas, :operador_id = 1).should == /operador/1/llamadas;exitosas route_for wraps ActionController::Routing::Routes.generate(options), so whatever route_for is producing is what rails actually produces. You may want to ask on the Rails list how people are approaching this w/ test/unit. If you get an answer, please report it back here. Cheers, David - controller.send(:operador_exitosas_llamadas_path,@operador).should == /operador/22/llamadas;exitosas but nothing works. any clue? thanks in advance -- Edgar González González E-mail: [EMAIL PROTECTED] http://www.hasmanydevelopers.com http://www.rubycorner.com http://www.to2blogs.com http://www.lacaraoscura.com -- ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] testing behaviour or testing code?
On 9/2/07, Pat Maddox [EMAIL PROTECTED] wrote:
On 8/24/07, David Chelimsky [EMAIL PROTECTED] wrote:
On 8/24/07, Pat Maddox [EMAIL PROTECTED] wrote:
On 8/24/07, David Chelimsky [EMAIL PROTECTED] wrote:
describe Widget, class do
it should provide a list of widgets sorted alphabetically do
Widget.should_receive(:find).with(:order = name ASC)
Widget.find_alphabetically
end
end
You're correct that the refactoring requires you to change the
object-level examples, and that is something that would be nice to
avoid. But also keep in mind that in java and C# people refactor
things like that all the time without batting an eye, because the
tools make it a one-step activity. Refactoring is changing the design
of your *system* without changing its behaviour. That doesn't really
fly all the way down to the object level 100% of the time.
WDYT?
I think that example is fine up until the model spec. The
find_alphabetically example should hit the db, imo. With the current
spec there's no way to know whether find_alphabetically actually works
or not. You're relying on knowledge of ActiveRecord here, trusting
that the arguments to find are correct.
Au contrare! This all starts with an Integration Test. I didn't post
the code but I did mention it.
What I've found when I write specs is that I discover new layers of
services until eventually I get to a layer that actually does
something. When I get there, it's important to have specs that
describe what it does, not how it does it. In the case of
find_alphabetically we care that it returns the items in alphabetical
order. Not that it makes a certain call to the db.
I play this both ways and haven't come to a preference, but I'm
leaning towards blocking database access from the rspec examples and
only allowing it my end to end tests (using Rails Integration Tests or
- soon - RSpec's new Story Runner).
Now that I've had a chance to play with Story Runner, I want to
revisit this topic a bit.
Let's say in your example you wanted to refactor find_alphabetically
to use enumerable's sort_by to do the sorting.
def self.find_alphabetically
find(:all).sort_by {|w| w.name }
end
Your model spec will fail, but your integration test will still pass.
I've been thinking about this situation a lot over the last few
months. It's been entirely theoretical because I haven't had a suite
of integration tests ;) Most XP advocates lean heavily on unit tests
when doing refactoring. Mocking tends to get in the way of
refactoring though. In the example above, we rely on the integration
test to give us confidence while refactoring. In fact I would ignore
the unit test (model-level spec) altogether, and rewrite it when the
refactoring is complete.
Here's how I reconcile this with traditional XP unit testing. First
of all our integration tests are relatively light weight. In a web
app, a user story consists of making a request and verifying the
response. Authentication included, you'll be making at most 3-5 HTTP
requests per test. This means that our integration tests still run in
just a few seconds. Integration tests in a Rails app are a completely
different beast from the integration tests in the Chrysler payroll app
that Beck, Jeffries, et al worked on.
The second point of reconciliation is that mock objects and
refactoring are two distinct tools you use to design your code. When
I'm writing greenfield code I'll use mocks to drive the design. When
I refactor though, I'm following known steps to improve the design of
my existing code. The vast majority of the time I will perform a
known refactoring, which means I know the steps and the resulting
design. In this situation I'll ignore my model specs because they'll
blow up, giving me no information other than I changed the design of
my code. I can use the integration tests to ensure that I haven't
broken any behavior. At this point I would edit the model specs to
use the correct mock calls.
As I mentioned, this has been something that's been on my mind for a
while. I find mock objects to be very useful, but they seem to clash
with most of the existing TDD and XP literature. To summarize, here
are the points where I think they clash:
* Classical TDD relies on unit tests for confidence in refactoring.
BDD relies on integration tests
* XP acceptance tests are customer tests, whereas RSpec User Stories
are programmer tests. They can serve a dual-purpose because you can
easily show them to a customer, but they're programmer tests in the
sense that the programmer writes and is responsible for those
particular tests.
In the end it boils down to getting stuff done. After a bit of
experimentation I'm thinking that the process of
1. Write a user story
2. Write detailed specs using mocks to drive design
3. Refactor, using stories to ensure
Re: [rspec-users] Deprecating the mocking framework?
On 9/2/07, Wilson Bilkovich [EMAIL PROTECTED] wrote: On 9/1/07, rupert [EMAIL PROTECTED] wrote: On 1 Sep 2007, at 10:04, Tom Stuart wrote: On 1 Sep 2007, at 09:31, rupert wrote: Are we planning on dumping the mock framework in favor of using Mocha The idea has been bandied around on the dev list recently This decision, if it is made in this manner, is suicide for RSpec. I simply don't understand this statement. Why is this such a big deal? RSpec's mock framework offers pretty much ZERO over mocha or flexmock - the only thing is that it saves you from typing 24 or 27 characters in a config file, depending on your preference. 21 if you use RR. After that, the functionality is pretty much the same as the other frameworks. I have been a huge RSpec booster, but this will make me drop it like a hot coal. Again - I can't understand where you're coming from here. If you start using test/unit or test/spec or any of the other bdd frameworks you'll still need to make a decision about a mock framework. What is the pain that you're perceiving that will come along w/ us dumping the mock framework? Perhaps there's something we can do to minimize that pain once we know what it is. Cheers, David =( ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Deprecating the mocking framework?
On 9/2/07, Scott Taylor [EMAIL PROTECTED] wrote: On Sep 2, 2007, at 12:55 PM, David Chelimsky wrote: On 9/2/07, Wilson Bilkovich [EMAIL PROTECTED] wrote: On 9/1/07, rupert [EMAIL PROTECTED] wrote: On 1 Sep 2007, at 10:04, Tom Stuart wrote: On 1 Sep 2007, at 09:31, rupert wrote: Are we planning on dumping the mock framework in favor of using Mocha The idea has been bandied around on the dev list recently This decision, if it is made in this manner, is suicide for RSpec. I simply don't understand this statement. Why is this such a big deal? RSpec's mock framework offers pretty much ZERO over mocha or flexmock - the only thing is that it saves you from typing 24 or 27 characters in a config file, depending on your preference. 21 if you use RR. After that, the functionality is pretty much the same as the other frameworks I'm a little confused about this discussion. Why don't we just do the following: 1. Hand off the mocking/stubbing framework off to someone else. It will be their project 2. Make the mocking/stubbing framework a dependency of the rspec gem 3. Make it the default (as it is now) 4. Provide clear directions for changing mocking frameworks (as we have now). I thought the end goal with refactoring the mocking framework out was not that we shouldn't be using it, but, that we (David, Aslak, Brian, etc) won't have to maintain it. Or am I missing something? Well, it's not simply a matter of US maintaining it. It's a matter of it being maintained at all in light of the fact that mocha and flexmock exist. Put simply, there never should have been an rspec mock framework. But here we are. In my view, we either put the thing to sleep or keep it part of rspec and forget the whole deprecation thing. Handling it off to someone else to maintain seems silly to me. FWIW, David Scott ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] testing behaviour or testing code?
On 9/2/07, Jay Levitt [EMAIL PROTECTED] wrote:
On 9/2/2007 12:43 PM, David Chelimsky wrote:
The problem we face is that AR promises huge productivity gains for
the non TDD-er, and challenges the thinking of the die-hard TDD-er.
I've gone back and forth about whether it's OK to test validations like
this:
it should validate_presence_of digits do
PhoneNumber.expects(:validates_presence_of).with(:digits)
load #{RAILS_ROOT}/app/models/phone_number.rb
end
On the one hand, it looks immediately like we're testing
implementation. On the other, we're not really - we're mocking a call
to an API. The confusion is that the API is represented in the same
object as the one we're testing (at least its class object). I haven't
really done this in anger yet, but I'm starting to think it's the
right way to go - especially now that we have Story Runner to cover
things end to end. WDYT of this approach?
Personally, I don't much like it. It feels too much like:
it should validate_presence_of digits do
my_model.line(7).should_read validates_presence_of :digits
end
I can write specs like that all day and ensure absolutely nothing about
my code.
I like to think of specs as a form of N-version programming where N=2
(or maybe N=3 now with Story Runner). By using a different vocabulary
to express the specs than the actual code, we are more likely to think
of the problem differently, and thus find places where the two versions
of our code differ. Sometimes, it means we miswrote the spec;
sometimes, it means we miswrote the code.
But if all your spec does is guarantee that your code reads a certain
way, you've done nothing but protect against accidental edits. And if
you're gonna go that way, why not go all the way:
it shouldn't change unless I change the spec too do
MD5.new(my_model).should == 0xDEADBEEF0FFD2FFE4...
end
I'd much rather see:
it should prevent me from entering anything but digits do
PhoneNumber.new(800-MATTRESS).should_not be_valid
end
And then, every time I find an edge case, I add another spec:
it should allow me to enter dashes do
PhoneNumber.new(800-555-1212).should be_valid
end
it should only allow 10 digits do
PhoneNumber.new(800-555-12121212).should_not be_valid
end
A couple of things to consider:
There's a very useful guideline in TDD that says test YOUR code, not
everyone elses. The validation library we're testing here is
ActiveRecord's. It's already tested (we hope!).
Also - there's a difference between the behaviour of a system and the
behaviour of an object. The system's job is to validate that the phone
number is all digits. So it makes sense to have examples like that in
high level examples using Story Runner, rails integration tests, or an
in-browser suite like Selenium or Watir.
This model object's job is to make sure the input gets validated, not
to actually validate it. If the model made a more OO-feeling call out
to a message library - something like this:
class PhoneNumber
def validators
@validators ||= []
end
def add_validator (validator)
validators validator
end
def validate(input)
validators.each {|v| v.validate (input)}
end
end
Then submitting mock validators via add_validator and setting mock
expectations that they get called would be totally par for the course.
In AR, the validators are added declaratively. This is a Rails design
decision that we have to either live with or write other code around.
Choosing to live with it, it seems to me that mocking the call to
validates_presence_of :digits is no different than mocking validate on
an injected validator.
That all make sense?
etc.
Jay Levitt
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] blog post on story runner
Here's an excellent blog post on Story Runner, which will be part of the next release and is undergoing active development in trunk: http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] testing behaviour or testing code?
On 9/3/07, Peter Marklund [EMAIL PROTECTED] wrote: There's a very useful guideline in TDD that says test YOUR code, not everyone elses. The validation library we're testing here is ActiveRecord's. It's already tested (we hope!). Personally, I don't have the courage to assume Rails code is always working. The school of thought that says test your code addresses this issue as well - you can have examples that specifically test assumptions in an API - but then they should be separated from your other examples (as they are not testing your code). Check out JUnit Recipes by J.B. Rainsberger. I know from experience it doesn't always work although it is quite solid in general. The Rails code has been tested but not in conjunction with my particular apps. I also want to test my assumptions of how the Rails API works, maybe it doesn't work as I think. Again - JB calls these learning tests. Having tests/specs that cover Rails interaction with my app, which higher level tests of course naturally do (system/integration tests), gives me much more courage to upgrade Rails as well. Agreed. And Story Runner is the perfect place for these. Cheers, David Peter ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Reason for _spec.rb convention
On 9/3/07, Scott Taylor [EMAIL PROTECTED] wrote: On Sep 3, 2007, at 7:59 AM, Ashley Moran wrote: Hi Easy one - I just wondered why all spec files for rspec_on_rails end _spec.rb instead of just .rb? They are all inside the spec folder so surely the fact they are specs is implicit? Personally, I think the only reason we keep it around is for Autotest, which maps xyz_spec.rb = xyz.rb. But - Feel free to name your specs however you choose. The autotest mapping you speak of ships with rspec, not ZenTest, so if we chose to rename the files there would be no problem. Scott ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Deprecating the mocking framework?
Hi all, I've talked this over w/ a couple of the other committers and we've decided that we will NOT be deprecating the mock framework, at least for the foreseeable future. If/when we do, it will happen with plenty of notice and a clear, painless (as much as is possible) upgrade path. To be clear: this decision is purely pragmatic. Benefits of the existing framework cited in this thread are significant (one-stop shop, generated specs for the rails plugin, etc). And the amount of work it would take to do it right (backwards compatibility, easy upgrade path, support for multiple external frameworks, etc) far exceeds the perceived cost of maintaining the existing framework. Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] 1.05 to 1.08
On 9/3/07, Shane Mingins [EMAIL PROTECTED] wrote: Hi We are looking at moving a project over from 1.05 to 1.08 but have a problem with some of our helper specs They work fine in 1.05 but error in 1.08 and it is the calls to route helper methods that seems to be the problem. I did some playing around .. because the code being tested is reasonably large etc ... but this sample (using the peepcode app) seems to boil down the problem describe WeathersHelper do it do weather = Weather.new weather.id = 1 weather_path(weather).should == /weathers/1 end end This passes in 1.05 and throws an exception in 1.08 ... is seems that the route helper method is not available. BTW, in our actual code the call to weather_path is in the helper ... I just put it in the above for simplicity. So I am wondering what may have changed and what do I need to configure?? I am going to guess that it's something like this: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil. If not, please post the error (good idea to do that in general). If so, this is fixed in trunk. Attached is a patch you can use to address it in your rails app (apply from vendor/plugins) Please let us know if this fixes the problem. Cheers, David Thanks Shane Shane Mingins ELC Technologies (TM) PO Box 247 Santa Barbara, CA 93102 Phone: +64 4 568 6684 Mobile: +64 21 435 586 Email: [EMAIL PROTECTED] AIM: ShaneMingins Skype: shane.mingins (866) 863-7365 Tel - Santa Barbara Office (866) 893-1902 Fax - Santa Barbara Office +44 020 7504 1346 Tel - London Office +44 020 7504 1347 Fax - London Office http://www.elctech.com Privacy and Confidentiality Notice: The information contained in this electronic mail message is intended for the named recipient(s) only. It may contain privileged and confidential information. If you are not an intended recipient, you must not copy, forward, distribute or take any action in reliance on it. If you have received this electronic mail message in error, please notify the sender immediately. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users helper_bug_fix.patch Description: Binary data ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Model Specs: Fixtures vs Mocks + Stubs?
On 9/4/07, Lance Carlson [EMAIL PROTECTED] wrote: What is the general opinion about fixtures versus mocking and stubbing in model specs? I heard from agile on IRC that they save the database testing for integration testing, but I also see that the caboose sample applicaiton uses fixtures. I also noticed that on the rspec site, it says Ironically (for the traditional TDD'er) these are the only specs that we feel should actually interact with the database. I wrote that bit - but it doesn't suggest that you should use fixtures or not. If I'm going to the DB I generally create the model objects I want right in the examples. re: fixtures - the argument against is that they are a pain to maintain - but there have been some recent developments like http://code.google.com/p/fixture-scenarios/ that seem promising. With the recent addition of Story Runner (in trunk), I'm exploring more and more the ideas espoused by Jay Fields on his blog re: mocking declarative API calls to AR (see http://blog.jayfields.com/2006/12/rails-unit-testing-activerecord.html) to support super-fast object-level examples in concert w/ end-to-end examples in Story Runner. So you have two separate issues here: 1. db or not db 2. if db, fixtures or not fixtures I doubt you'll find general consensus on either question. Good luck! Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Failure Messages in RSpec
On 9/4/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote:
Having used JUnit and Test::Unit, I'm quite used to having the ability to
insert a failure message, which helps when tests fail.
For instance, the example RSpec that is generated for a model class
specifies that the model class is valid. Assuming this were supposed to be
true, and it failed, I've now got to duplicate the code in the test in order
to find out why it wasn't valid.
Whereas if I were writing the same code in Test::Unit, I might write:
assert model.valid?, Expected model to be valid, but found these errors:
#{model.errors}
This means that when the model validation fails, I know /why/. I don't see
an easy way to include these sorts of messages in RSpec, which seems likely
to cause me to waste time on test failures. Am I missing something? How
are experienced RSpec users resolving this?
I come from the same background as you, so I hear where you're coming
from. We made a conscious decision, however, not to support custom
messages almost two years ago and I'm not sure if its ever even come
up before. If it has, it was a long time ago.
If you follow the conventions of one expectation per example, and your
example is well named, this is less of a problem. Here's a common
idiom:
describe Person do
def valid_attributes
{:name = 'joe smith'}
end
before(:each) do
@person = Person.new(valid_attributes)
end
it should be valid with valid attributes do
@person.should be_valid
end
it should be invalid with no name do
@person.name = nil
@person.should_not be_valid
end
end
Together, these different examples help to tell the whole story, and
when one example fails you know why it's failing - its just that the
message is in the example's name instead of a custom assertion
message.
Make sense?
Thanks,
- Geoffrey
--
Geoffrey Wiseman
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Rake tasks getting in the way of edge (uses gem instead)
On 9/4/07, Pat Maddox [EMAIL PROTECTED] wrote: So I'd been running gem releases of rspec for the past several months, and I installed edge rspec so that I can use Story Runner. I'm running into a problem because I've got a couple rake tasks that reference spec/rake/raketask. If I try to run rake spec then it pulls in the gem version instead of the plugin version. rake blows up saying that the versions are incompatible...RSpec is at 1.0.8 and rspec_on_rails is at r2507. If I remove those rake tasks then it runs fine. So it just seems that when rake starts up, it loads all the available task files, which includes a reference to require rspec stuff. Since the plugins haven't been loaded yet it gets the gem version. afaik the solution is to build a new gem. However I don't want to have to tell my team members to update their gem every single day. Also I think including rspec in vendor/plugins is supposed to obviate that anyway, but this is probably just some path loading stuff. Anyone else run into this? How do you handle it? See http://rspec.rubyforge.org/documentation/rails/install.html Pat ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Failure Messages in RSpec
On 9/4/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote:
I come from the same background as you, so I hear where you're coming
from. We made a conscious decision, however, not to support custom
messages almost two years ago and I'm not sure if its ever even come
up before. If it has, it was a long time ago.
[nod] Perhaps as I get into the mindset, I'll find this desire slips away.
If you follow the conventions of one expectation per example, and your
example is well named, this is less of a problem. Here's a common
idiom:
describe Person do
def valid_attributes
{:name = 'joe smith'}
end
before(:each) do
@person = Person.new(valid_attributes)
end
it should be valid with valid attributes do
@person.should be_valid
end
it should be invalid with no name do
@person.name = nil
@person.should_not be_valid
end
end
Using this as an example, if a new validation rule is added, this test will
fail without indicating /why/. Sure, I can get that answer in other ways,
but I'd hate to discover things like:
it should be valid with valid attributes do
# puts @person.errors if [EMAIL PROTECTED]
@person.should be_valid
end
(Which I've seen when people have to repeatedly diagnose issues in a test;
I'd prefer a failure message to the above)
Together, these different examples help to tell the whole story, and
when one example fails you know why it's failing - its just that the
message is in the example's name instead of a custom assertion
message.
Make sense?
Yes and no; test isolation and good names is a decent practice even in
XUnit, but clearly it's that much stronger in RSpec, and I'm in favour of
that. However, I find that often test failures involve unexpected changes (
e.g. the REST service didn't return a status code of 201, as you expected,
because a validation rule changed and the validation failed), which aren't
as easy to message.
Still, i'm willing to give this approach a shot and see if this bothers me
increasingly less.
Personally, I'm open to the idea of custom messages - I just have no
idea how that work syntactically. If you get to the point where you
really feel the need for that feature (or before that point) please
feel free to make suggestions about that.
Cheers,
David
- Geoffrey
--
Geoffrey Wiseman
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] 1.05 to 1.08
On 9/4/07, Shane Mingins [EMAIL PROTECTED] wrote: On 4/09/2007, at 3:44 PM, David Chelimsky wrote: I am going to guess that it's something like this: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil. If not, please post the error (good idea to do that in general). If so, this is fixed in trunk. Attached is a patch you can use to address it in your rails app (apply from vendor/plugins) Please let us know if this fixes the problem. Cheers, David Boiled down the next routes problem in a helper spec ... using with_routing it do with_routing do |set| set.draw do |map| map.resources :articles do |article| article.resources :comments, :name_prefix = 'a_' do | comment| comment.resources :ratings, :name_prefix = 'a_c_' end end end a_c_rating_path(@article, @comment, @rating).should == / articles/1/comments/1/ratings/1 end end This works fine in 1.05 and errors in 1.08 with the error: NoMethodError in 'CommentsHelper NO NAME (Because of Error raised in matcher)' The NO NAME part is because you wrote 'it do' with no message passed to it. You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil. This looks like the same error - can you run just the file w/ this spec like this: spec path/to/file.rb -b That'll produce the full backtrace. Thanks Cheers Shane ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] False Positives and Autotest on New Folders
On 9/5/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote:
False Positives
I just discovered how easy it was to create a false positive when I, trying
my first RSpec test, did this:
ob.should eql?('foo')
instead of:
ob.should eql('foo')
or:
ob.should == 'foo'
As far as I can see, this is roughly equivalent to:
ob.should false
Neither eql?('foo') nor false causes the spec to fail; this is worrisome, as
I can imagine accidentally including that ? again; and I'd hate it to mask a
test failure.
Please report bugs to http://rubyforge.org/tracker/index.php?group_id=797
Autotest
Out of curiosity, does anyone know how to get autotest to pick up new
folders under spec/? Seems like I might have to modify rails_rspec.rb in
lib/autotest. We were considering separating our acceptance tests from the
rest.
- Geoffrey
--
Geoffrey Wiseman
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Caveman Questions
On 9/5/07, sudara [EMAIL PROTECTED] wrote:
Hello!
I'm just a caveman with some caveman questions.
I've been parsing Rspec for quite a while, and I'm writing my first series
of specs. My initial impressions are Verbose, but understandable. Helpful
and intuitive, but so much to digest. I want to congratulate the folks who
are dedicating a chunk of their lives to writing this, and ask 2 caveman
questions
My first is Why lambda in rpsec? It doesn't strike me as reads like
english or easily understandable. I understand it's place in ruby (um,
kind of :), but my thinking is:
lambda { do_something_risky }.should raise_error
would be more understandable (and fun!) written as:
running { something_risky }.should raise_error
That's a great idea. Why don't you add it to the tracker:
http://rubyforge.org/tracker/index.php?group_id=797
My second question is: For those folks who are getting up to speed with ruby
and rails AND digesting rspec along the way, there is a lot of incoming DSL.
As I started with rails before rspec, I found myself using script/console to
check my code, poking at different ways of expressing myself with ruby.
Is there a way to poke at my specs? I can load up my test environment, but
can I spec things live so that I can find out what works and what doesn't?
I find I'm wasting a chunk of time (as I don't have the DSL even 60% down)
writing specs and getting it wrong. Am I missing a trick, or I.should_have
dsl_down_before_trying.else_return(crying)?
irb(main):001:0 require 'rubygems'
= true
irb(main):002:0 require 'spec'
= true
irb(main):003:0 include Spec::Matchers
= Object
irb(main):004:0 5.should == 5
= nil
irb(main):005:0 5.should be 4
Spec::Expectations::ExpectationNotMetError: expected 4, got 5
Cheers,
David
um, thanks for any potential caveman responses - the more caveman
(pragmatic) the better.
sudara
--
View this message in context:
http://www.nabble.com/Caveman-Questions-tf4384357.html#a12498949
Sent from the rspec-users mailing list archive at Nabble.com.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Preconditions
On 9/8/07, Pat Maddox [EMAIL PROTECTED] wrote: On 9/8/07, Wincent Colaiuta [EMAIL PROTECTED] wrote: El 8/9/2007, a las 2:15, Pat Maddox escribió: * Descriptions should be broken up based on the required fixture. I don't split them up until I actually have to. For example, if I'm writing a Stack class. I'd probably start off with [snip] For a simple spec like this it's okay. We could factor out the Stack.new call, and there's one other smell, but we'll get to that in a minute. Now what if we want to peek the stack? [snip] Now we've got clear duplication in three places: (1) The constructor (2) Call to add_item (3) the 'it' specifier! It's clear that the fixture for should not be empty and should let you peek are the same. They're also different from the should be empty so we split them up: [snip] There are two key benefits to that. The first is that it's obvious where new specifications need to go. The behavior for #pop whether a stack is empty or has an item is going to be different. Also if you need some behavior that changes with 3 items, you can probably figure out that you should create a new description. An even bigger benefit is that it minimizes the brain processing required to figure out a spec. If you create the fixture in the setup and don't vary it, it's trivial to scan through some simple expectations. This has to do with the smell that I alluded to earlier, which was the call to add_item. Ideally your example will contain just one expectation and no other setup. This reduces the concepts that change from example to example. Change is where bugs pop up most of the time. So if you're doing setup in an example, then you probably want to split it out from the current description. In fact, in real life I would have split the descriptions up immediately after writing the should not be empty example. Brilliantly written example, very clear! +1 Cheers, Wincent ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users To give credit where it's due, I'm pretty sure that's from my memory of the early examples on rspec.rubyforge.org. Thanks for that Pat. We pulled that tutorial down a while ago but you can get the textile source for it like so: svn export svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0/doc/src/tutorials Cheers, David Pat ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] why no newlines in failure messages?
On 9/8/07, Jeremy Stell-Smith [EMAIL PROTECTED] wrote: Instead of : expected ul\n lired/li\n liblue/li\n/ul, got ul\n lired/li\nliblue/li\n /ul (using ==) could we make rspec exceptions look more like : expected ul\n lired/li\n liblue/li\n/ul, got ul\n lired/li\nliblue/li\n /ul (using ==) Trunk's already doing this. Not released yet. or if that is too hard, even : expected ul\n lired/li\n liblue/li\n/ul, got ul\n lired/li\nliblue/li\n /ul (using ==) then it becomes readily easy to scan the two values and see differences, as opposed to (something I have done far too often in the last few months) copying the diff, pasting it somewhere and manually doing this. I have looked at the --diff option, but it doesn't show how something has changed, just where it has changed which is not quite what I want. Jeremy ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] template.expects_render?
On 9/8/07, Leslie Freeman [EMAIL PROTECTED] wrote: Hi All, I'm trying to make use of template.expects_render, is outlined in David's post(http://blog.davidchelimsky.net/articles/2007/06/28/ template-expects_render). I get an undefined method error on expects_render. I made sure I had the 1.0.8 gem as well as reinstalling the plugin and redoing the bootstrap. Still no luck. So I created a clean project, installed the CURRENT plugin, ran script/ generate rspec and generated a vanilla rspec scaffold. I added the template.should_render to a view spec, and am still getting the undefined method error. I had assumed this method would be available in 1.0.8, as it was supposed to be added to 1.0.6. Am I wrong? Or am I missing something crucial about the usage? Thanks, Leslie Below is my view spec: require File.dirname(__FILE__) + '/../../spec_helper' describe /apples/index.rhtml do include ApplesHelper before do apple_98 = mock_model(Apple) apple_99 = mock_model(Apple) assigns[:apples] = [apple_98, apple_99] end it should render list of apples do template.should_render(:partial = 'apples/apple') The method is expect_render, not should_render. HTH, David render /apples/index.rhtml end end ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] changes to TextMate bundle
Hi all, I got some help from James Edward Gray II on the RSpec TextMate bundle. For those of you who don't know James, he runs the Ruby Quiz and also maintains the official TM bundle. Per a couple of patches from him and some advice that I acted on, many of the shortcuts have changed. The bad news is you'll have to learn new shortcuts. The good news is that the new shortcuts follow TextMate conventions (which they really should have from the beginning). The other good news is that we may have a chance to get the bundle into the TextMate repo once we get done w/ the current Story Runner merge. Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Preconditions
On 9/8/07, Ben Mabey [EMAIL PROTECTED] wrote: What was the motivation behind taking that tutorial down, BTW? I really like and benefited from it when I was starting to learn rspec. Was it just a maintenance issue as far as updating the tutorial to the current API (DSL)? That was part of the deal. The other part was that I thought it would be more demonstrative to have something w/ two or more classes dealing w/ interactions. Just never got around to it. We should probably resurrect the Stack tutorial in the mean time. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Content assist for spec files
On 9/5/07, Tor Norbye [EMAIL PROTECTED] wrote: Hi there, I'm working on Ruby support for NetBeans, and we're bundling RSpec (along with JRuby). One thing I'd really like to fix is having content assist (code completion / intellisense / code insight, it has many names) work inside your spec files such that you can not only hit ctrl-space and see describe, before, it etc. but also see the documentation for these methods. The problem is that when I'm looking at a spec file, there are no require-statements. Obviously, the methods I see called in the spec files must be defined by the test runner itself before running the spec file. Can somebody enlighten me as to what that context looks like? (As an example, in Ruby on Rails view files, I treat the file as if it's extending ActionView::Base, so all the methods on that class (and included modules and such) all become available as methods you can call from the view. I was wondering if there was a similar class, or set of Modules, that I can use to simulate the context for the code inside the _spec.rb file.) Hi Tor - we're in the middle of a significant refactoring that is intended, in part, to make jobs like the one you are trying to do easier. I can tell you where to look right now, but it is subject to change over the next couple of weeks. To get an idea, the files you're interested in are currently in /lib/spec/dsl and lib/spec/matchers. I'll try to follow up as things settle down. Feel free to ask here if any specific questions come up. Cheers, David -- Tor ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can NOT overides the stub! in the setup
On 9/10/07, bruce zuo [EMAIL PROTECTED] wrote: Hello, I am new to rSpec. I tried to search in the list, but could not find the answer, please forgive me if somebody already answered this. Here is my question: I have a stub in setup: before(:each) do @current_user = mock(devsu) # Generally, prefer stub! over should_receive in setup. User.stub!(:find).and_return(@current_user) session[:user] = @current_user.id end Where User is a model. Then I tried to overrides it within a spec in a rails CONTROLLER specs: it descriptions do ... User.should_receive(:find).with(3).and_return(mock_user) get 'show', :id = 3 end I found only '3', that is right, only single quotes can overrides the stub! in setup, the 3, double quotes won't work. I am wondering if this is the way how it works? What's the error that you get when you use double quotes? Thanks. --Bruce ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] changes to TextMate bundle
On 9/10/07, Scott Taylor [EMAIL PROTECTED] wrote: What happened to pending (with and without the block)? Uh my dog ate it? I don't think it was in there. Or perhaps it wasn't in there correctly, because James found some errors in the bundle related to items that had no names. Feel free to patch 'em back in if you're in a hurry. If not, just raise a bug and I'll get to it soon. Scott On Sep 10, 2007, at 3:50 PM, Bryan Liles wrote: On Sep 10, 2007, at 11:41 AM, Bryan Liles wrote: These patches are in trunk already? Yes they are. -- -- r2544 | dchelimsky | 2007-09-08 17:43:01 -0400 (Sat, 08 Sep 2007) | 1 line reworked textmate bundle shortcuts per conversation w/ James Edward Gray II re: TextMate conventions ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Going beyond the default html formatter/report?
On 9/11/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote: On 9/9/07, Priit Tamboom [EMAIL PROTECTED] wrote: I wonder does anybody planning to go beyond the default html formatter/report? Two things on that subject came up today, during some RSpec work. It would be nice if: The report contained pending messages, when specified, e.g.: describe Secure passwords with MD5 do pending Waiting on selection of an MD5 library. end The HTML report contains 'Secure passwords with MD5' as pending, but does not add the explanation as to why. It would be nice to be able to use DHTML expansion to see the source of the spec, sometimes; when we're doing walkthroughs with the customer representative, it's useful for him to be able to see the source as well as the descriptions. - Geoffrey These are great suggestions. Please, please, please put these in feature requests where they are guaranteed to stay on the radar and not on this list where they are guaranteed to get lost in the shuffle. Cheers, David -- Geoffrey Wiseman ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can not 'assigns' value in View test
On 9/12/07, Evan David Light [EMAIL PROTECTED] wrote:
Granted that I'm new too; however, assigns[:hash] creates a member
variable @hash that is made available to the view. Maybe that's the
problem? Modify your view to use @hash instead.
http://rspec.rubyforge.org/documentation/rails/writing/views.html
On Sep 12, 2007, at 5:20 AM, Shaker wrote:
Hello everyone:
I am quit new to View test using rspec. I want to write spec for a
partial, which is rendered by a controller. However, the controller
does not
pass data to the partial using instance variables, it uses symbol
variable
instead. I read the example of view spec provided in the website.
But the
example is using instance variable. So I am looking for a way of
assigning
my test data to the partial to be tested. I would like to show an
my code
below:
class MyController
def index
hash = {...#data provided here}
render :partial='index', :layout=false, :locals={:hash=hash}
end
end
_index.rhtml
..#unrelated code omitted
script
var data = %= hash %;
!-- process data here --
/script
In my spec, I used assigns[:hash] = my_own_data, but an error
occurred,
saying that undefined local variable or method 'hash' .
How can I assign my own data to hash in my view spec?
Thank you!
--
View this message in context: http://www.nabble.com/Can-not-%
27assigns%27-value-in-View-test-tf4428018.html#a12631788
Sent from the rspec-users mailing list archive at Nabble.com.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Philosophical questions
On 9/12/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote: On 9/12/07, David Chelimsky [EMAIL PROTECTED] wrote: I like to start w/ integration tests before anything exists at all. You can do that w/ Rails' Integration Tests or Story Runner (if you're using RSpec's trunk). Next, I hit a view. ... Despite the time involved, I'd love to see a written tutorial or screencast that walks this whole gamut in order if someone ever has time to do one. Me too! - Geoffrey -- Geoffrey Wiseman ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Philosophical questions
On 9/12/07, Evan David Light [EMAIL PROTECTED] wrote: On Sep 12, 2007, at 7:35 PM, David Chelimsky wrote: Story Runner is a new one for me. I'll have to look it up. Thanks! (Halfway through writing this, I realized, courtesy of Google, that it's a recently integrated piece of functionality into RSpec-on-Rails. I found this example of yours captured here. ) Not specific to Rails at all. Just happens to support Rails. Gotcha. Tomorrow I'll be checking out from trunk. Although it behooves me to ask if the RSpec (and integration tests/story runner) in trunk all pass. Pass? Pass? Puh-lease!! We don't commit to trunk w/ out 100% coverage in core (not there yet for the rails plugin) and all rails plugin specs passing against 1.2.1, .1.2.2 and .1.2.3. We also run them against edge rails, but we just use that to keep issues on the radar - passing against edge is not a pre-condition for committing. Seems like sound common sense. I caught myself earlier today writing a spec for a non-functional portion of my view, chided myself for it, ripped out the spec, and then continued. Careful here. Business value is not always measured in terms of things functional. Sometimes it's the company logo showing up in the right place on the page after spending thousands of marketing dollars figuring out where that spot is. Granted. Anything that is a customer requirement should be captured at some level. That said, the Rails app that I'm writing at the moment is a tool to support an RD effort so none of that sort of thing there. Good to realize that I'm not thinking that far off the mainstream here. Eeeek. You're not thinking far off from ME. That in no way makes it main stream. Hehe. Ok, I'm thinking like a guy who has prolific dialogues about how to build better software. I could do worse. ;-) Well - my earlier post was more like a monologue than dialog, but thanks! Cheers, David Evan ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can not 'assigns' value in View test
On 9/12/07, Shaker [EMAIL PROTECTED] wrote:
Unfortunately, I am not supposed to change the code inside the partial.
That's why I posted this message. I am trying to find a way of tackling this
problem. Because I am going to test tens of hundreds of partials, most of
which are using the symbols rather than instance variable.
Huh? Symbols in the partials that are supposed to magically transform
to some value? I don't get it. What am I missing?
David Chelimsky-2 wrote:
On 9/12/07, Evan David Light [EMAIL PROTECTED] wrote:
Granted that I'm new too; however, assigns[:hash] creates a
member
variable @hash that is made available to the view. Maybe that's the
problem? Modify your view to use @hash instead.
http://rspec.rubyforge.org/documentation/rails/writing/views.html
On Sep 12, 2007, at 5:20 AM, Shaker wrote:
Hello everyone:
I am quit new to View test using rspec. I want to write spec for a
partial, which is rendered by a controller. However, the controller
does not
pass data to the partial using instance variables, it uses symbol
variable
instead. I read the example of view spec provided in the website.
But the
example is using instance variable. So I am looking for a way of
assigning
my test data to the partial to be tested. I would like to show an
my code
below:
class MyController
def index
hash = {...#data provided here}
render :partial='index', :layout=false, :locals={:hash=hash}
end
end
_index.rhtml
..#unrelated code omitted
script
var data = %= hash %;
!-- process data here --
/script
In my spec, I used assigns[:hash] = my_own_data, but an error
occurred,
saying that undefined local variable or method 'hash' .
How can I assign my own data to hash in my view spec?
Thank you!
--
View this message in context: http://www.nabble.com/Can-not-%
27assigns%27-value-in-View-test-tf4428018.html#a12631788
Sent from the rspec-users mailing list archive at Nabble.com.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
View this message in context:
http://www.nabble.com/Can-not-%27assigns%27-value-in-View-test-tf4428018.html#a12646459
Sent from the rspec-users mailing list archive at Nabble.com.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can not 'assigns' value in View test
On 9/12/07, Shaker [EMAIL PROTECTED] wrote:
I also feel puzzled. But that's what my colleagues do, and it works. The
thing is they use
render :partial='index', :locals={:hash=hash}
in the controller to pass the hash data to the partial it will render(index
in this case). And later they simply use %= hash % to get the hash data
passed from the controller.
Now THAT is a horse of a different color. OK - first:
render :partial='index', :locals={:hash=hash}
Here, the symbol :hash is just a key - it is not the object that's
been passed around.
Second:
%= hash %
I'm assuming that's in the partial named index (a partial named
index???, now THAT's not at all confusing). In this case, the
:locals = {:hash=hash} in the calling template assigns the hash
object (in the calling template's scope) as the return value of a
method in the partial named (drum roll, please) hash. Like
hash().
So - what you want to do is to stub the hash method on the template:
template.stub!(:hash).and_return(the_hash_I_want_to_stick_in_the_template)
That all make sense?
Good luck!
Maybe the :locals does some magical work here. I
am quite familiar with rspec and ruby. So I am reading more documentation
now.
Hopefully we could figure it out shortly.
David Chelimsky-2 wrote:
On 9/12/07, Shaker [EMAIL PROTECTED] wrote:
Unfortunately, I am not supposed to change the code inside the partial.
That's why I posted this message. I am trying to find a way of tackling
this
problem. Because I am going to test tens of hundreds of partials, most of
which are using the symbols rather than instance variable.
Huh? Symbols in the partials that are supposed to magically transform
to some value? I don't get it. What am I missing?
David Chelimsky-2 wrote:
On 9/12/07, Evan David Light [EMAIL PROTECTED] wrote:
Granted that I'm new too; however, assigns[:hash] creates a
member
variable @hash that is made available to the view. Maybe that's the
problem? Modify your view to use @hash instead.
http://rspec.rubyforge.org/documentation/rails/writing/views.html
On Sep 12, 2007, at 5:20 AM, Shaker wrote:
Hello everyone:
I am quit new to View test using rspec. I want to write spec for a
partial, which is rendered by a controller. However, the controller
does not
pass data to the partial using instance variables, it uses symbol
variable
instead. I read the example of view spec provided in the website.
But the
example is using instance variable. So I am looking for a way of
assigning
my test data to the partial to be tested. I would like to show an
my code
below:
class MyController
def index
hash = {...#data provided here}
render :partial='index', :layout=false, :locals={:hash=hash}
end
end
_index.rhtml
..#unrelated code omitted
script
var data = %= hash %;
!-- process data here --
/script
In my spec, I used assigns[:hash] = my_own_data, but an error
occurred,
saying that undefined local variable or method 'hash' .
How can I assign my own data to hash in my view spec?
Thank you!
--
View this message in context: http://www.nabble.com/Can-not-%
27assigns%27-value-in-View-test-tf4428018.html#a12631788
Sent from the rspec-users mailing list archive at Nabble.com.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
View this message in context:
http://www.nabble.com/Can-not-%27assigns%27-value-in-View-test-tf4428018.html#a12646459
Sent from the rspec-users mailing list archive at Nabble.com.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
View this message in context:
http://www.nabble.com/Can-not-%27assigns%27-value-in-View-test-tf4428018.html#a12646774
Sent from the rspec-users mailing list archive at Nabble.com.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can not 'assigns' value in View test
On 9/12/07, Shaker [EMAIL PROTECTED] wrote:
Hello, David:
Thank you very much for your help. Now it works!
I would like to recall a message posted several days ago regarding the
paginate. How to test paginate in controller spec? One simple example
may be like this:
hash[:accounts_pages], hash[:accounts] = paginate :accounts(the table),
#order and conditions follows
How should I test this code in controller spec? Or can I mock this line,
like should_receive(:paginate).and_return(...)? But the problem is
'paginate' returns two values. :(
When a method returns 2 values it is really returning an array, so ...
and_return([val1, val2])
See if that works.
Thanks for investigating this question.
David Chelimsky-2 wrote:
On 9/12/07, Shaker [EMAIL PROTECTED] wrote:
I also feel puzzled. But that's what my colleagues do, and it works. The
thing is they use
render :partial='index', :locals={:hash=hash}
in the controller to pass the hash data to the partial it will
render(index
in this case). And later they simply use %= hash % to get the hash data
passed from the controller.
Now THAT is a horse of a different color. OK - first:
render :partial='index', :locals={:hash=hash}
Here, the symbol :hash is just a key - it is not the object that's
been passed around.
Second:
%= hash %
I'm assuming that's in the partial named index (a partial named
index???, now THAT's not at all confusing). In this case, the
:locals = {:hash=hash} in the calling template assigns the hash
object (in the calling template's scope) as the return value of a
method in the partial named (drum roll, please) hash. Like
hash().
So - what you want to do is to stub the hash method on the template:
template.stub!(:hash).and_return(the_hash_I_want_to_stick_in_the_template)
That all make sense?
Good luck!
Maybe the :locals does some magical work here. I
am quite familiar with rspec and ruby. So I am reading more documentation
now.
Hopefully we could figure it out shortly.
David Chelimsky-2 wrote:
On 9/12/07, Shaker [EMAIL PROTECTED] wrote:
Unfortunately, I am not supposed to change the code inside the
partial.
That's why I posted this message. I am trying to find a way of
tackling
this
problem. Because I am going to test tens of hundreds of partials, most
of
which are using the symbols rather than instance variable.
Huh? Symbols in the partials that are supposed to magically transform
to some value? I don't get it. What am I missing?
David Chelimsky-2 wrote:
On 9/12/07, Evan David Light [EMAIL PROTECTED] wrote:
Granted that I'm new too; however, assigns[:hash] creates a
member
variable @hash that is made available to the view. Maybe that's
the
problem? Modify your view to use @hash instead.
http://rspec.rubyforge.org/documentation/rails/writing/views.html
On Sep 12, 2007, at 5:20 AM, Shaker wrote:
Hello everyone:
I am quit new to View test using rspec. I want to write spec
for a
partial, which is rendered by a controller. However, the
controller
does not
pass data to the partial using instance variables, it uses symbol
variable
instead. I read the example of view spec provided in the website.
But the
example is using instance variable. So I am looking for a way of
assigning
my test data to the partial to be tested. I would like to show an
my code
below:
class MyController
def index
hash = {...#data provided here}
render :partial='index', :layout=false,
:locals={:hash=hash}
end
end
_index.rhtml
..#unrelated code omitted
script
var data = %= hash %;
!-- process data here --
/script
In my spec, I used assigns[:hash] = my_own_data, but an error
occurred,
saying that undefined local variable or method 'hash' .
How can I assign my own data to hash in my view spec?
Thank you!
--
View this message in context: http://www.nabble.com/Can-not-%
27assigns%27-value-in-View-test-tf4428018.html#a12631788
Sent from the rspec-users mailing list archive at Nabble.com.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
View this message in context:
http://www.nabble.com/Can-not-%27assigns%27-value-in-View-test-tf4428018.html#a12646459
Re: [rspec-users] Philosophical questions
On 9/13/07, Evan David Light [EMAIL PROTECTED] wrote: My immediate impression was Story == Use Case. Story == User Story User Stories are not the same thing as Use Cases. You may want to google around for some writing on that. Cheers. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Need help in View Spec
On 9/13/07, Shaker [EMAIL PROTECTED] wrote: Yes, I have gone through the documentation before, and I read the reference of 'assert_select' as well. But I still can not figure out a way of testing attributes in a tag. What I know is we can use: should have_tag(tag#id) or should have_tag(tag.class) to select a tag, whereas I don't know how to select an attribute and test it! That's all covered in the assert_select docs. Here's a cheat sheet you might find useful. http://labnotes.org/svn/public/ruby/rails_plugins/assert_select/cheat/assert_select.html so you can do this: response.should have_tag(form[action=?][method=post], foo_path(@foo)) HTH Another problem is the tag does not have id or class sometimes, does it mean that is no way of selecting it? David Chelimsky-2 wrote: On 9/13/07, Shaker [EMAIL PROTECTED] wrote: I can not find much information about the should have_tag syntax in Rspec. http://rspec.rubyforge.org/rdoc-rails/classes/Spec/Rails/Matchers.html#M11 ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- View this message in context: http://www.nabble.com/Need-help-in-View-Spec-tf4439760.html#a12667582 Sent from the rspec-users mailing list archive at Nabble.com. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Need help in View Spec
On 9/13/07, Shaker [EMAIL PROTECTED] wrote: I can not find much information about the should have_tag syntax in Rspec. http://rspec.rubyforge.org/rdoc-rails/classes/Spec/Rails/Matchers.html#M11 ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Need help in View Spec
On 9/13/07, Shaker [EMAIL PROTECTED] wrote: Sorry, that's another spec caused the error. It is working. Thank you very much Glad you got it worked out. Cheers, David Shaker wrote: Hello To spec the example I mentioned before, I wrote the spec as what you suggested #../view/group/index_spec.rb describe /group/_index_spec do it should call JS function when click the button do render '/group/_index' response.should have_tag(input[onclick=?], update()) end end However, it generated an error Expecting a selector as the first argument. What is wrong? David Chelimsky-2 wrote: On 9/13/07, Shaker [EMAIL PROTECTED] wrote: Yes, I have gone through the documentation before, and I read the reference of 'assert_select' as well. But I still can not figure out a way of testing attributes in a tag. What I know is we can use: should have_tag(tag#id) or should have_tag(tag.class) to select a tag, whereas I don't know how to select an attribute and test it! That's all covered in the assert_select docs. Here's a cheat sheet you might find useful. http://labnotes.org/svn/public/ruby/rails_plugins/assert_select/cheat/assert_select.html so you can do this: response.should have_tag(form[action=?][method=post], foo_path(@foo)) HTH Another problem is the tag does not have id or class sometimes, does it mean that is no way of selecting it? David Chelimsky-2 wrote: On 9/13/07, Shaker [EMAIL PROTECTED] wrote: I can not find much information about the should have_tag syntax in Rspec. http://rspec.rubyforge.org/rdoc-rails/classes/Spec/Rails/Matchers.html#M11 ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- View this message in context: http://www.nabble.com/Need-help-in-View-Spec-tf4439760.html#a12667582 Sent from the rspec-users mailing list archive at Nabble.com. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- View this message in context: http://www.nabble.com/Need-help-in-View-Spec-tf4439760.html#a12667734 Sent from the rspec-users mailing list archive at Nabble.com. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
