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...
Related
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.
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.
I am beginning to adopt Test Driven Design (TDD) behaviors and workflow for my iOS development projects. There is at least one impediment though in the context of legacy software. I will often have to add features to a pre-existing code base that I am new to. I will typically want to refactor at the beginning of working with the code base which will often have no tests available to ensure that my refactor-ings are not altering code functionality or worse, adding bugs.
My question is how do TDD folks bootstrap the whole process when the code is not written from scratch but rather legacy code that they are brought in to work on?
Thanks,
Doug
UPDATE
For a concrete example, I am using the example from Martin Fowler's Refactoring re-coded in Objective-C as a training device for TDD (and AppCode) >>
I built the code from tests. I found I needed to add instance variables to the Customer class to ensure I didn't screw up the cost calculations in the statement method as I grew the code. This is the fundamental issue I need insight into.
To begin with, if you don't understand the legacy code you're working with, you need to fix that before you do things which you're concerned may change behavior.
In your situation, after understanding the legacy code, I would write tests that will run against that legacy code. Once you're satisfied that these tests function as you expect, you're in a much better position to test your refactored code to ensure it functions as the old code did.
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)