I'm sick of writing out the same controller specs each time I make a new controller. I know I can use the scaffold generator, but there are enough little things I have to change that it usually doesn't save me much time.
Are there any projects/tools out there that provide some sort of base set of specs and/or a DSL to make this easier?
I've never found that any two REST controllers I wanted to write had similar enough interfaces that the tests were at all similar (and generally, I recommend Cucumber, not controller specs).
Something like inherited_resources or Rails 3's respond_with is very useful for writing the controllers, but I'm not sure about the tests.
I use the decent_exposure gem.
Related
I have a Sinatra app with the following structure:
controllers
helpers
models
views
public
I will be using RSpec for testing it. For me, there are two variants of tests - to test with Rack::Test::Methods - to check responses, the content of body and so on, and the second - to test the "core" logic - for example if the method "find_most_expensive" really returns the item with maximum price, to check if a new product is really created and that kind of things.
What I'm wondering is how to organise this tests in the spec folder? Should I have only name_of_controller_spec.rb files and both kind of tests go there? Or should they be separate? And how? To sum up, I have never written tests and I don'y know how exactly and where to put them :( Any kind of advise would be appreciated! :)
You could make just three folders: controllers (with, for example, posts_spec.rb), models (that contains post_spec.rb where testing the methods you have implemented in your model) and helpers (let's say utils_spec.rb).
Take a look at Testing Sinatra with Rack::Test and some repositories on GitHub to have a better idea on how you should organize your code.
https://pragprog.com/book/7web/seven-web-frameworks-in-seven-weeks
The source code is free and it has a chapter on Sinatra tests.
I know, I just ran them as I updated the expect instead of should deprecation warnings.
Only they use shell scripts to test with but you may already be familiar with what you want to use. The point is notice just different names for the folders and not the tests? Maybe could work for you. I like the answer first posted. These can both relate perhaps.
Something I had noticed with Rubocop is to keep your test methods in as little as 25 lines or they fail there. So I would say keep them broken down into small groups.
Ruby koans has tests that you could look at too.
I just completed writing a detailed rspec capybara integration and unit tests for Rails app, which includes mocking Omniauth (twitter) login, filling in forms, data validations, etc. However, I am wondering whether there is a need to write a separate controller or functional test.
Would appreciate your input and any links to further readings etc.
I'll play devil's advocate here, since I know I'm probably in the minority with this opinion: I actually prefer to do exceedingly thorough controller testing. A few reasons:
1) I find it easier to systematically test every path and outcome at the controller level than at the integration test level. My integration tests are primarily just happy-paths, and some of the more common error paths.
2) A lot of potential security issues occur at the controller level. Thorough testing helps me ensure that nothing malicious can get through to my model logic.
3) This is subjective, but it really forces me to think about some of the long-tail paths that my application might go through. What if someone tries to for an invalid password reset token into the URL? Controller testing ensures that I consider all options.
4) Unlike integration tests, they're fairly straight-forward to test. Each action is just a ruby method!
Personally, I think if your request (integration) spec is exercising all code paths you're covered. Ryan Bates has a great Railscast about how he tests here: http://railscasts.com/episodes/275-how-i-test?autoplay=true and about 5:05 in he says a similar thing. Like you I like to write integration tests rather than controller specs. Most of the time controllers simply front CRUD type operations anyway (especially if you're careful about keeping domain logic out of the controller), so all you're testing is the scaffolding.
We have a isolated test automation team responsible for automating only watir+cucumber functional test cases. Their code base is not attached with the rails app that other developers are working on, but kept separate. We have automated several test cases so far, and now what problem we have is, some (watir/cucumber specs)test cases require some data to be preexist into db, so it(testcase) should focus only on the problem stmt, and not creating any data-require itself.
Example, say if it has to check whether rating is working for a post, it requires a post object should preexist and it just checks rating. And not creating 1st post object and then checking its rating.
What are the best approaches here? Like we have fixtures and factory-girl for rails unit testing, what is there for cucumber specs? Or Shall we make use of features only here? These testers may not have idea of all models that exist, do they be aware of them so to make use of fixtures by calling Rails-Model interface.
My idea was, when we write feature file, it should not point or talk about any Model which looks meta stuff. Watir/specs test cases should only be aware of "Web-application"/browser only as the interface to talk/deal with the application. They should not know any other interface(fixture/Models). Hence they should create their own data on their own, by making use of the single interface they know.
Again, what I want to know that, is there any ruby lib/code, given table names, column names, and values(all most like fixtures yml), along with db parameters. It will simply insert them into db, without context of rails environment. And so testers those are having their environment isolated from rails web developers would able to work on their own. Rails fixtures, or factory girls seem to be well coupled with rails. Or am I incorrect?
Like Chirantan said you could use Factory girl with cucumber.
As require your factories in test unit or RSpec, you can do the same in the cucumber's env.rb file or any custom config file.
http://robots.thoughtbot.com/post/284805810/gimme-three-steps
http://www.claytonlz.com/2010/03/zero-to-tested-with-cucumber-and-factory-girl/
http://www.andhapp.com/blog/2009/11/07/using-factory_girl-with-cucumber/
When using cucumber, the Given statement sets the test situation up:
Given I have a basic user with a password
and the When statement triggers the test:
When the user logs in
and the Then statement checks the test results
Then they see the basic menu
The data gets loaded in the Given statement.
I wrote my own FaceBook library that uses actual Curl requests, not libcurl.
Is there a way to test it? I'm asking this because most solutions involve using something like fakeweb which as far as I can tell will not work here.
The existing code can be found on my github page.
One approach would be to use a different host/port in test mode (eg localhost:12345)
Then in your test run a sinatra or webrick servlet on that port that you configure to respond to the requests your code should be making
You could mock Request.dispatcher with an expected behavior, pretty much like Fakeweb would do.
There are a few examples on this file, specially https://github.com/chrisk/fakeweb/blob/master/lib/fake_web/ext/net_http.rb#L44.
When running your tests/specs, monkey-patch the run method of your Request class to hook into the Marston VCR library. See the existing library_hooks subdir for examples and ideas on how to do this -- the fakeweb implementation is a good place to start.
VCR works well with live services like Facebook's because it captures interactions "as is", and VCRs can be easily re-recorded when the services change.
I'm running into problems with your library, however. You need to require the cgi and json libraries; it also looks like it requires a Rails environment (it's failing to find with_indifferent_access on Hash).
I am writing a Ruby on Rails app. which will use a 3rd party to do a webservice call or a rest call or some sort of call. I am not sold on which 3rd party I am going to use so I want to isolate this in some sort of facade.
If I was doing this in .NET, I would isolate this functionality in a service that I inject into the controller. This means I can easily mock out the service in order to make it testable but in ruby, it is much easier to mock things so I don't think I need this level of indirection and de-coupling that I would need in a static application.
This feels very un-ruby-like and I would like to hear how more experienced ruby developers approach this problem of isolating the code to make it mockable and testable and also give me the option to swap which 3rd party provider I am using.
If it is a RESTful webservice, I would do this in a model that inherits from ActiveResource::Base. It should be relatively easy to mock this out as well for testing purposes.
The ruby-like version of "I would isolate this functionality in a service that I inject into the controller" would be something like "I would write this as a ruby module that I include in my class"