How do we test a Rails Model which does not have an equivalent table in the backend using RSpec - ruby-on-rails-3

I have a Moderator model which basically queries web site related stat results from other models.
An e.g. of displayed stats could be the total number of users belonging to a particular area out of many areas in a city. Limiting the number of such records to a fixed number. For this, the body defined within the Moderator model makes use of an Area model.
Since the queries are not using anything from the same model, but actually from other models, there wasn't a need for me to have a table migration wrt this model.
I basically am now trying to test the defined methods in the Moderator model using Rspec.
What I am basically trying to test is that a call to the method should return success, this I am doing through:-
subject.send(:method_name)
response.should be_success
I'm getting a common error for all such defined methods saying that database_name.table_name does not exist. Well , this is true but how should is it really making a difference?, and how to get a work around for this to just test a simple use case of calling a method successfully in the above context.
Thanks.

Try something like this
describe Moderator do
it "should do something" do
moderator = Moderator.new
moderator.something.should == "do"
end
end
This assumes that you have a method something on Moderator and that it returns the string "do".
I think the RSpec Book provides great information and examples if you want to get more in-depth with your rspec.

Well,
The below line code did work for me:-
Model_name.method_name.should_not be_nil

Related

Rails 5 after removal of assigns function for controller tests

I used assert_template and assigns extensively before Rails 5 in my controllers tests. For example to test that a link in the view is correct:
assert_select ".left-off-canvas-menu ul li a[href=?]", event_all_items_path(assigns(:event)), "Back to all items"
I figured that assert_template was not difficult to get rid of.
However, I don't know how to replace test cases like the one above.
I know about the gem to include those functions, but I'd like to try without them. So alternatives would be:
Would you make a case to keep the assigns function or would you say it is meant to be hard coded?

Rails 3 Sunspot Solr Conditional Search Only Applied To New Records

I'm trying to perform a query and find 20 records recently created across multiple models using the sunspot_solr gem. Currently it achieves that no problem, but I wanted to add some extra validations for only one of the models that were being searched.
Currently in my User model it lists all new users that were created, but I only want it to list users who have confirmed their email address. I'm using Devise for user authentication and using active record to find all users who have not been confirmed I would do something along the lines of:
User.where("confirmed_at is null")
Or the reverse to test for the opposite. I tried to integrate this with my solr search as so...
Model
#Unless the user being searched hasn't been confirmed...
searchable :unless=> proc { |user| user.confirmed_at == nil } do
time :created_at
time :confirmed_at
end
Controller
#updates = Sunspot.search(Upload,Help,User) do
without(:confirmed_at, nil)
order_by(:created_at, :desc)
paginate page: 1, per_page: 20
end
However this added condition only eliminated user records created after the condition was added to the model. I'm not completely sure how indexing works, but it seems to be caching old information where the newely added conditions weren't being applied. I can confirm this by creating a new user record and I notice immediately it doesn't get indexed until I validate the email address.
What I've tried:
Stopping and restarting server
Stopping server and attempted to stop and restart solr but this produced a PID could not be found error
After reading up a little more on indexing I confirmed my suspicions and found out that I had to re-index my search. To do this I looked at Sunspot readme and found this line:
bundle exec rake sunspot:solr:reindex
I have a bad habit of trying to make use of technologies before I even understand what they do...

What's a good way to insert a resource id into the params of another resource?

I'm really new to programming, so I'm having trouble explaining this -- please forgive.
I have a Document model and a Note model in my rails app. A note belongs to a document, and a document has many notes -- the foreign key in the notes table is document_id.
On my document show page, I have a form for a note which uses a :content attribute as a text_area field.
What I'd like to do is pass the document's id into the note params so the note would have both the :content the user submits alng with the :document_id based on the document_path.
Currently I'm adding the :document_id into the note's params hash using a hidden_field form helper, and sending the whole thing to the NotesController, but I hope there's a cleaner / perhaps easier way.
If this makes sense, can someone suggest a better way to do this? Thank you.
In your routes have something like
resources :documents do
resources :notes
end
Then you should be adding a note via this route
/documents/5/notes/new
Then in your NotesController have
def create
#document = Document.find(params[:document_id])
#note = #document.notes.build(params[:note])
if #note.save
# Blah
else
# Blah
end
end
(In no way has this been tested - but it gives you an idea of how to do it in a RESTFUL style without hidden fields)

Rails-3.1 nested routes creating same action and controller, basic lack of knowledge

Doing the following routes configuration:
resources :cadeiras do
resources :professores
end
resources :cadeiras do
resources :fichas
end
resources :fichas do
resources :exercicios
end
will generate me 2 different links to the same controller and action, running rake routes ill get something like:
fichas GET /fichas(.:format) {:action=>"index", :controller=>"fichas"}
cadeira_fichas GET /cadeiras/:cadeira_id/fichas(.:format) {:action=>"index", :controller=>"fichas"}
The first action will reference all the 'fichas' while the second on is referencing only 'fichas' from 'cadeiras' how is it possible to distinguish the two actions?
I would like to avoid three level nesting problems as described here :http://weblog.jamisbuck.org/2007/2/5/nesting-resources
Thank you for your time
If I understand your question correctly, the answer is "you don't distinguish them" :
The exact same action is executed from the controller, rendering the exact same view. The difference is the collection of 'fichas' that get sent to the view:
- in the first case, all fichas are available in the view
- in the second case, only the 'fichas' related to the 'cadeira' are available in the view (e.g. /cadeira/1/fichas will display only the 'fichas' related to the 'cadeira' with id 1)
To determine which records to show (e.g.) in an index view, you can do something like this:
unless cadeira_id = params[:cadeira_id]
#fichas = Ficha.all
else
#fichas = Cadeira.find(cadeira_id).fichas
end
The rest is up to the view: it should render fichas the same way, you just chose which records are actually made available to it.

Ruby on Rails 3: rails_admin + puret?

Did someone try to integrate puret into rails_admin? I can't make a language switch to edit different translations :(
Changing I18n.locale forces whole rails_admin to use specified locale.
Now I got the solution. The two can work together well. In short:
Delete the pureted column(s) in your model
If you have the column pureted still in your model, rails form helper will bypass puret. That is, if a model called Post has a field called contents to be i18ned, the table posts SHOULD NOT have the column contents.
Actually we should use globalize3 instead. With this you do not need to remove the original column. And puret doens't support nested attributes assignment. globalize3 works very well.