Having a terrible time finding RSpec-2 (and rspec-rails) documentation. Specifically I want to look up all available Matchers... but how?
I've tried:
RSpec.info : outdated - RSpec 1.x
rdoc.info : seems useless, to me anyway. (incomplete?)
RSpec-Relish : confusing. incomplete? how would one look up available Matchers?
GitHub Wiki : scattered info. unorganized. incomplete?
Yes, I'm aware of The Book...but, seriously, isn't this stuff online?
Even tried rake doc:plugins but it didn't work. Too green to know why...
apparently there used to be some decent 1.x docs on rspec.rubyforge.org. but they're appear to be long gone...
Where are these docs hiding?
The first place to go is the official Relish docs, they have gotten a significant improvement over the years and are now my first place to look.
At the time of writing this answer originally, this gist was solid. It contains matchers for the following:
Capybara
Paperclip with Shoulda
Rspec Rails
Rspec Exceptions
Shoulda Matchers
Not sure why you feel rdoc.info isn't useful - here's the matcher docs there:
http://rubydoc.info/gems/rspec-expectations/2.0.1/RSpec/Matchers
It may be that you're looking in the wrong spot; these were in the RSpec::Expectations gem, which is split out from the core in Rspec 2.
Related
I'm trying to learn to do TDD. I'm having difficulty though, finding out what exactly it is I should be testing for each action in a RESTful controller. What I really would like is a sample of the most basic spec for a RESTful controller, which would help me figure out what I should be testing. If it matters, I'm using RSPec with Capybara. I'm not looking for something I can crib, just a sample I can examine so I know whether I'm going in the right direction.
There was an answer here before that got deleted, and the user suggested the Rails tutorial. It was pretty good for learning what to test, and can be found at http://www.railstutorial.org/book with chapters three and nine being most useful for someone just looking at it for TDD purposes.
Since then I've also found an older article that's really handy combined with the tutorial (and a bit of digging), simply because it's now highly out of date. This is found at the Everyday Rails blog, at http://everydayrails.com/2012/03/12/testing-series-intro.html.
Ultimately it looks like there may not be a good, solid, easy tutorial on how and what to test for Rails 4 with RSpec 3. Perhaps something you pros could consider!
I've been following the Ruby on Rails Tutorial. The author uses Rspec/Capybara's Describe/It for the whole tutorial. But recently I've seen people using Feature/Scenerio instead. I wonder if Feature/Scenerio is a replacement of Describe/It or something that is used together? If it is a replacement, is there any reason of prefer it over Describe/It?
The same question came up to me lately too. And I went to Capybara's github page to read more about it (search for scenario). Apparently feature, scenario and background are just aliases to make acceptance tests more readable. And I guess that's for legacy reasons -- cucumber uses those keywords. Therefore by aliasing them, capybara acceptance specs read more like traditional cucumber specs.
So no, feature/scenario/background are not a replacement of describe/it/before. As a group of methods, it is only an alternative for acceptance specs. It's up to you and your team to decide which ones to go with.
I am new to writing test for rubyonrails app like rspect, steak, cucumber etc. How do I start or learn so that it will help me to write beautiful codes?
You can give some simple example or some url where I can understand from zero.
Thanks
http://railscasts.com/episodes/155-beginning-with-cucumber - a good podcast for beginner
The RSpec Book - also very useful
It's a good point to start and then Google help you
1) Start by reading the rails testing guide just to get a feel for testing.
2) Become familiar with the various testing frameworks (Cucumber, rspec, testunit, steak, minitest), watch screencasts (railscasts, TeachMeToCode) and then try and choose one that appeals to you.
3) Write tests!! and get help as you need it from StackOverflow. If you like RSpec then the RSpec book is very helpful, but not essential.
My personal opinion on frameworks:
I started out really liking cucumber but I eventually found it very verbose and I didn't like using it for my integration tests and then RSpec for my unit and functional tests. I now like using just RSpec with Capybara and Shoulda matchers. TestUnit can be even less verbose than RSpec but personally I find RSpec to be the happy medium between writing self documenting code and not being overly verbose.
I've just started with RSpec a few days ago and it was pretty hard (it still is actually). You could start from railstutorial.org. The author follows the TDD principle. More info available at RSpec and Cucumber github page. Be sure to check out the wiki.
I'm coming from C#, and recently I started to write some Ruby on Rails applications.
My biggest problem with it is the documentation because I find it extremly difficult to use. For example, finding out how to call generator from my controller took me about 2 hours and then 15 minutes after that I found Rails::Generators.invoke method to figure out what arguments should I pass to this function.
Maybe I use the documentation the wrong way; First I take a wild guess and search in the Netbeans code completion, which is rarely helpful, then I search in Google, then go with the API.
Can some experienced Rails programmer give me some advice?
If you're new to rails I recommend you read a book before you dive into the API documentation.
Here are two recommendations:
Agile Web Development With Rails - Great introduction and reference on how to use rails.
Programming Ruby 1.9: The Pragmatic Programmers' Guide - More on Ruby. Great references!
After you've worked your way through those books, you'll have an idea of how Rails is designed and where to look for stuff.
Both books are great reference books. If you want to access the Rails and Ruby API's online, make sure to checkout RailsApi.com
I am describing my own very personal workflow with Ruby/Rails documentation:
You can use ri and rdoc if you are familiar with the console, but...
Personally, I recommend two very good Ruby/Rails documentation sites:
apidock.com (no good search, but sometimes fine examples)
railsapi.com (very good AJAX search, plus you can customize what documentation you would like to see - by versions and by Gems)
Every iteration of the Rails guides (http://guides.rubyonrails.org/) has a ton of useful stuff in it. That should be the first stop.
After that I search away in the API - http://api.rubyonrails.org.
Sometimes I even end up just reading the source code trying to find things - https://github.com/rails/rails.
I think the best place in the source code to be reading is in here - https://github.com/rails/rails/tree/master/railties/lib/rails.
I upvoted each of the other answers here.
I just started to document a rails application. I know this is actually done by rdoc, so I followed some rdoc guides regarding syntax and so on, but I got stuck when I tried to describe attributes of models, validations and the relationship between models, mostly because these things are part of ActiveRecord. So I wonder if there is some guide or a good practice regarding how to document a rails application or if there is something I'm missing?
I know that I could put all of this in the class description, but I wonder if there is a way more closely tied to the declaration itself (has_many, validates_presence_of, etc.) and what about the attributes?
I personally prefer YARD - http://yardoc.org , as it does a better job in documenting IMHO.
I don't know if there's a specific handler for Rails available, but it's quite easy to write one - http://yardoc.org/guides/extending-yard/writing-handlers.html
A good example might be the attribute handler - part of the yard gem:
lib/yard/handlers/ruby/attribute_handler.rb
Remember your tests are part of the documentation (for developers), particularly if you are using Cucumber where scenarios are easy to read. If you keep your methods very short and there is a test method with a descriptive name e.g. "should set the users name" I find I typically don't need comments on the method.
Validations or other parts of Rails I would not document. Part of being a Rails developer is understanding how these work, I think it is a fair assumption that another maintainer of your code reading it down the road will know validations, or other things built in to Rails. By that same logic, if you can use features of the framework or happy paths (not deviate much) with [documented] third party code, a lot of the documentation will be written for you.