Hello all.
I’m working with rails and came to a situation that i cannot imagine
how to test this.
Given i have an index action that retrieves me a collection of
objects.
But some of them have especific permissions.
My index action act like this:
- retrieve public objects.
- retrieve permission 1 objects.
- retrieve permission 2 objects.
So i have to write 3 tests.
it “should retrieve public objects”
context “permission 1”
it " should retrieve permission 1 objects"
context “permission 2”
it “should retrieve permission 2 objects”
Until here no problems because only conditional tests and method
calls.
But how i would test the “Index.retrieve_objects_from_permission1” ?
supose i have
class Index < ActiveRecord::Base
has_many :permissions
def self.retrieve_objects_from_permission1
Index.all(:conditions => “permissions.id = 1”, :include
=> :permissions)
end
def has_permission1
!self.permissions.find_by_id(1).nil?
end
end
My Index.retrieve_objects_from_permission1 would be:
it “should retrieve objects that have permission 1” do
@collection = Index.retrieve_objects_from_permission1
@collection.each do |c|
c.has_permission1.should == true
end
end
Is it right? ( I didn’t see it before on other’s code, so i don’t
think it’s right.)
Sorry for my poor english. i hope I have been clear enough.
Thank you 
Dear Mr. Learner,
Please note that while very similar in functionality, specs’ philosophy
differs from tests’ (especially from non-TDD ones).
That is, you write spec first, see it fail, and write some code to make
it
pass.
If you happen to write any implementation code first, you should
disregard
it while writing a spec.
You may find BDD reading in abundance on the internets.
To get a more substantial reply, I think you might want to describe what
you
want your code to do in plain English, and the community will hopefully
help
you to express that in rspec.
Cheers,
Costa.
Costa Shapiro,
Thank you for paying atention.
But How i would write if i don’t know nothing about the code ?
My problem is:
I have a messages listing section that will differ according of type
of user and according with message permission.
I have messages that are public and private.
Anyone can see public messages.
The private messages only can be accessed by who participate on them
and users that have Owner role on system.
How it would be tested ?
Since my listing have to list:
if user not owner:
- public messages + messages that the user can view because he
participate on them
if user is owner:
- all messages.
So i think the behavior that i have to spec is:
context “guests” do (for ex.)
before(:all) do
#mock a guest here
end
it “should see all public messages”
it “should see all messages that participate”
end
context “owners” do
before(:all) do
#mock a owner here
end
it “should see all messages”
end
Right?
I’ll be grateful, if you could give any hint about the spec code.
Greets,
Alright, as far as I know, the most common approach is to make up some
data for each controller spec, and one of the techniques for doing
this is fixtures (e.g. found in rails) – another is the mocks, of
course.
Fixtures aren’t exactly the hottest offer today, but to me, they are
probably the easiest choice for those messages of yours.
So, I suppose you may want to type in some message data in the
corresponding fixture file. (see
http://ar.rubyonrails.org/classes/Fixtures.html etc).
If you insist on mocking the messages, that would primarily go into
before :all block.
Then, in the blocks like ‘it “should see all public messages”’ you
make requests with the correctly mocked user and check the returned
messages versus the test data (you know which messages are supposed to
return).
Good luck,
Costa.
On 21 July 2010 22:41, tests learner [email protected] wrote:
But How i would write if i don’t know nothing about the code ?
Well, you do know something about the code. You don’t know what the code
is
exactly, but you should have a overall grasp of the different aspects of
the
feature you’re adding and how people are going to be interacting with
the
feature. A good way to think about your app (which has become popular
thanks
to stuff like Cucumber) is a “top-down” approach. So, you’d start with
what
the people using your app are going to see in different cases. For each
case, you think about what the view is going to do to show the user the
right thing. Then you think about what the controller is going to do so
the
view has what it needs to show the right thing. Then you think about
what
the model is going to do so that the controller has what it needs.
Which
tools you use to test the different parts of your app is another matter,
and
you can look further into that as you go along, but I’ve always found
the
top-down approach to be a good way to keep your head straight and not
get
lost in all the details.
So… getting back to your example. To expound on what Costa is saying,
if
you’re writing a model method that runs a query, then don’t worry about
how
what you put in the method or what query is going to be run, at first.
You’re just thinking about scenarios, and what sort of data you want the
method to return in these scenarios. To write the tests, you’ll want to
populate your test database with some records that correspond to the
scenarios that you want to test. Ideally, you also include records that
don’t fit inside the scenario. Then in your tests you call the method
you’re
testing and verify that the records that should be returned, are, and
the
ones that shouldn’t, aren’t. That should at least solve the model side
of
things.
– Elliot
