There is a great tool rustdoc (currently used by cargo) to test examples of documentation comments in Rust. Does rdoc or yard give us something similar in Ruby?
Well, there few examples of doctest tool in Ruby, and the most fresh one (for now) is yard-doctest:
Meet YARD::Doctest - simple and magical gem, which automatically parses your #example tags and turn them into tests!
Probably no so powerful as rustdoc, but it does what it needs to.
Related
I have read through Q&A/articles that explain the ideal structure of a Ruby project. I read the RubyGems guides on how to create a Ruby gem. I have just read a Q&A asking at what point a ruby project becomes a ruby gem but I can not for the life of me see the difference between the two. The structure seems to be the same. The files, where they go, everything looks the same to me. Is it how they're used? Can someone please explain the difference between the two to me?
The question that must be answered respect to 'Gemify' or not is: am I writing something that is readily reusable in a different context? If the answer is yes then your application is a candidate for 'Gemification'. If not then generally it is not worth the additional complexity to convert a Ruby project into a Gem.
For example. If one makes a CLI Ruby application that collects mortgage rates from multiple vendors and updates a database then there are two ways this could be converted into a gem.
First: You could generalise the interface/configuration and make it useful as a plugin/add-on/extension to projects written by someone needing the same or similar functionality. So someone could add the gemified version to their project and use it to do the grunt work for them and just make use of the results. This describes the most common use case for gems.
Second: However, you could also extract the framework of your CLI project layout into a generator gem for others to easily create their own CLI project layouts. This is how Rails came to be.
Basically are there things I should avoid doing in ruby that may break cucumber.
Bonus points if you can make me understand cucumber more as someone who went from c# to picking up ruby.
Things "I should avoid doing in ruby that may break cucumber"? No. Cucumber is a language-agnostic testing framework. Cucumber's goal is to express use cases in human-readable language that serves as both business specifications and executable test scenarios. In fact, cucumber was initially forked out of rspec, so it's a product of the the ruby open-source community. You'll likely run into some gotchas along the way, but there's no magic bullet. You just have to read the docs (of which there are plenty) and ride the learning curve.
I've been reading the README for the MSpec project, and though it does a lot of explaining about what it is and (what it is not) with several contrasts between itself and RSpec, there's nothing about why it exists. Would using RSpec (at the time of starting MSpec) have caused problems in some way, or was it missing some features? Are these things still true? Could an extension have been (or be) written for RSpec that would do this? Is it something political?
There's obviously a lot of documentation and examples for RSpec, more features and more updates to the library, and since MSpec seems harder to use IMO (considering the differences in feature set and my own comfort level with RSpec) I'd be very interested if anyone knows the reasons. Perhaps that sounds critical, but that's not my point, I'm just trying to supply some context - there are likely to be good reasons for all of this and that's what I wish to find out.
From the README:
MSpec attempts to use the simplest Ruby language features so that beginning
Ruby implementations can run the Ruby specs.
This was designed for incomplete implementations (Specifically Rubinius) of the base Ruby language. It doesn't use all the language features of Ruby, so it's easier to bootstrap your implementation to the point where you can run mspec's.
If you aren't creating a new implementation for the Ruby language, then you shouldn't use this.
What are some good example open source Ruby projects that use Cucumber and RSpec well?
Update: While the suggestions below where quite impressive, I wanted to see how others are using RSpec and Cucumber to drive product development.
From Quora:
Teng Siong Ong, Ruby, Python, etc.
https://github.com/teambox/teambox
I find it really nice that the RSpec project is tested with both Cucumber and RSpec itself:
https://github.com/rspec/rspec-core/tree/master/features
https://github.com/rspec/rspec-core/tree/master/spec
Cucumber is also self-hosted test-wise:
https://github.com/aslakhellesoy/cucumber/tree/master/features
I've also found it very useful that Aruba, a library of steps for testing CLI apps with Cucumber, is itself tested with Cucumber:
https://github.com/aslakhellesoy/aruba/tree/master/features
RubySpec is a rather ambitious effort to write specs for the Ruby language.
Does Ruby have any tools along the lines of pylint for analyzing source code for errors and simple coding standards?
It would be nice if it could be integrated with cruisecontrolrb for continuous integration.
Or does everyone write such good tests that they don't need source code checkers!
I reviewed a bunch of Ruby tools that are available here
http://devver.wordpress.com/2008/10/03/ruby-tools-roundup/
most of the tools were mentioned by webmat, but if you want more information I go pretty in depth with examples.
I also highly recommend using Metric-Fu it gives you a on gem/plugin install of 3 of the more popular tools and is built with cruisecontrolrb integration in mind.
The creator has a great post that should help get you up and running in no time.
http://jakescruggs.blogspot.com/2008/04/dead-simple-rails-metrics-with-metricfu.html
There has been a lot of activity in Ruby tools lately which I think is a good sign of a growing and maturing language.
Check these out:
on Ruby Inside, an article presenting Towelie, Flay and Simian, all tools to find code duplication
Towelie
flay
Simian (a more general tool that supports Ruby among other languages)
reek: a code smell detector for Ruby
Roodi: checks the style of your Ruby code
flog: a code complexity analyzer
rcov: will give you a C0 (if I remember correctly) code coverage analysis. But be careful though. 100% coverage is very costly and doesn't mean perfect code.
heckle: changes your code in subtle manners and runs your test suite to see if it catches it. Brutal :-)
Since they're all command-line tools they can all be integrated simply as cc.rb tasks. Just whip out your regex skillz to pick the important part of the output.
I recommend you first try them out by hand to see if they play well with your codebase and if you like the info they give you. Once you find a few that give you value, then spend time integrating them in your cc.
One recently-updated interesting-looking tool is Ruby Object Oriented Design Inferometer - roodi for short. It's at v1.3.0, so I'm guessing it's fairly mature.
I haven't tried it myself, because my code is of course already beyond reproach (hah).
As for test coverage (oh dear, I haven't tried this one either) there's rcov
Also (look, I am definitely going to try some of these today. One at least) you might care to take a look at flog and flay for another style checker and a refactoring candidate finder.
There's also the built-in warnings you can enable with a quick:
ruby -w
Or setting the global variable $VERBOSE to true at any point.
Code metrics on ruby toolbox website.
Rubocop is a widely-used static code analyzer.
I just released Excellent which implements several checks on Ruby code. It combines roodi, reek and flog and also adds some Rails specific checks:
gem sources -a http://gems.github.com
sudo gem install simplabs-excellent
May be helpful...