Cucumber for Web testing: better Ruby or JRuby? - ruby

I need to set up the automation framework of a Web project using cucumber and researching about the subject I see people who're using Ruby and others who are using JRuby, but I cannot see any article or explanation about what's the difference between the two in his context.
Any idea which one I should go for and why it could be better that one?

cucumber is a language-agnostic, behavior-driven testing tool. It allows stakeholders to create human-readable product specifications that also serve as executable test scenarios. So--relative to the tool--cucumber doesn't care what language you are using.
The difference between ruby and jruby is that jruby is an implementation of the ruby language in Java.

Related

When using ruby and cucumber does it limit things I can do with ruby

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.

What is the reason for the MSpec library?

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?

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.

Which testing tools do what in Ruby?

What I mean by that is, which tools are for unit testing, which for BDD, is there even a clear divide?
I'm just learning Ruby from C#, and the tools I'm familiar with there are xUnit-style for pure unit testing/TDD, and Cucumber/SpecFlow for BDD/integration testing. Of course, you can use unit testing tools for integration testing if you want to.
The main testing tools I've come across for Ruby are Test::Unit, RSpec, and Cucumber (there are obviously plenty more but these seem to be the most popular, and hence probably a good bet to start off with).
I'm not looking for a long list of tools here - if there's a main contender I've missed then please tell me, but I'd rather keep it simple at this stage than start using 'Tool Z beta with the Library X extensions running on the MegaChode platform' or whatever. I'm only a poor confused .Net guy, after all!
It's clear that Test::Unit was designed for unit testing, and Cucumber is for BDD. But I'm not sure about RSpec - some people seem to use it as a low-level unit testing tool, and others for higher-level BDD. At the same time, some people seem to use Test::Unit (and similar) with additional libraries for BDD.
To give you an idea of where I'm coming from, the way I see it is that you can write more functional, testable specifications (which a business guy might understand) with your BDD tool and then do low-level, developer-focussed TDD with your unit testing tool as you implement the functionality required for your Cuke (or whatever).
Is there a generally accepted way of doing these things in Ruby, or do I need to forget about such a crazy notion and use whatever seems to do the job?
Cheers,
Grant
I think most Rubyists have standardized on RSpec rather than Test::Unit for testing. If you're doing Rails apps, there is RSpec-Rails and then Cucumber you can layer on top of it.
Grab a copy of The Rspec Book # http://www.pragprog.com/titles/achbd/the-rspec-book
MiniTest contains both an xUnit and spec style testing interface (with the ability to combine them both in the same file).
It is included as part of the standard gems since Ruby2.2.
Both can be included in the same file which makes it easy to convert between the styles or other testing tools like RSpec and Test::Unit
require 'minitest/autorun'
describe Math do
describe 'addition' do
it '1+1=2' do
(1+1).must_equal 2
end
end
end
class MathTest < Minitest::Test
def test_1_plus_1_equal_2
assert_equal 2, 1+1
end
end
MiniTest also includes a mocking framework (although I prefer rr)

Code and unit tests in two different languages?

I've recently have started writing unit tests for PL/SQL code in Ruby.
Are there any other language combinations where you write your code and unit tests in two completely different languages?
A common combination is code in Java and tests in Groovy. Which is particular interesting because Groovy is built "on top of" Java, for example Groovy even uses the same testing framework as Java.
We write groovy tests for our Java application. Mainly cause we want to learn and experience other programming languages.
I've seen unit tests written in Ruby for a C library wrapped with swig.
The main advantage compared to the same unit tests written in C being the interactive Rub interpreter (irb) that permits to do exploratory testing.
Few years ago we used Python to test C++ code, using Boost to export classes.
Unit tests were written in python.
The interesting part of this architecture is that we were able to access to living objects from a python console, because the logic was expressed in python, C++ was used to build low level classes.
If you're adding a new language to an existing project it's perfectly reasonable to do functional/acceptance tests in the existing language.
When we first adopted Ruby on Rails, we still used JUnit and HTMLUnit to test the web front-end and did assertions directly against the database backend.
If you're still learning how to use a new piece of infrastructure it makes sense to keep using a testing method that you can trust whilst you do the transition.
We did eventually start using test/unit in ruby, and selenium - but it was useful to a transition period where we relied on our existing Java-based tests...

Resources