How it would be tested?

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
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

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 => “ = 1”, :include
=> :permissions)

def has_permission1


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

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 :slight_smile:

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
If you happen to write any implementation code first, you should
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
want your code to do in plain English, and the community will hopefully
you to express that in rspec.


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
it “should see all public messages”
it “should see all messages that participate”

context “owners” do
before(:all) do
#mock a owner here
it “should see all messages”

I’ll be grateful, if you could give any hint about the spec code.


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
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 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

Good luck,

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
exactly, but you should have a overall grasp of the different aspects of
feature you’re adding and how people are going to be interacting with
feature. A good way to think about your app (which has become popular
to stuff like Cucumber) is a “top-down” approach. So, you’d start with
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
view has what it needs to show the right thing. Then you think about
the model is going to do so that the controller has what it needs.
tools you use to test the different parts of your app is another matter,
you can look further into that as you go along, but I’ve always found
top-down approach to be a good way to keep your head straight and not
lost in all the details.

So… getting back to your example. To expound on what Costa is saying,
you’re writing a model method that runs a query, then don’t worry about
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
testing and verify that the records that should be returned, are, and
ones that shouldn’t, aren’t. That should at least solve the model side

– Elliot