- Posted by Shay Friedman on April 30, 2010
As I’ve told you before, I’m going to talk about IronRuby and IronRuby on Rails in the upcoming Norwegian Developer Conference.
However, it’s not only me that’s talking about IronRuby in NDC2010! Scott Bellware and Ben Hall both have one or more talks involving the Ruby language and how you can exploit it in your .NET development process.
In total, NDC is hosting 5 (!) different IronRuby-related sessions and by that, it is the first one to acknowledge the importance of IronRuby to the .NET community. Kudos for that!
With that in mind, I’m happy to announce that there’s more!
Scott came up with the idea, Anders helped with the organization and it came alive: the Ruby Meetup in NDC 2010!
The Ruby Meetup is going to take place during launch time of the last day of the conference – June 18th, 12:50-13:40 featuring Scott Bellware, Rob Conery, Ben Hall and myself!
The idea is simple – the panel is about Ruby and IronRuby but we don’t have anything prepared except our knowledge. This means that it’s up to you to come with the questions/comments/problems/whatever and throw them at us!
Hoping to see you all there!
Shay.
P.S. If one of you can bring a CD with IronRuby to the meetup, then we can drop it and finally find out if it makes a sound!
- Posted by Shay Friedman on April 29, 2010
This June is going to be SENSATIONAL!
On mid June I’ll be doing my way towards Norway to participate in the Norwegian Developer Conference, AKA NDC2010. This conference has a really awesome lineup and I’m really honored to take part in it.
The conference will take place on June 16-18 in Oslo Spectrum in Oslo.
I’ll be doing two sessions, both on the last day of the conference:
When: June 18th, 09:00
Title: Practical IronRuby
Abstract:
Ruby has been a home for some great innovative frameworks like Ruby on Rails, Cucumber and Rake. IronRuby version 1.0 has recently been released, unleashing the power of Ruby to the .NET world.
In this session you will get familiar with the Ruby language and its amazing ecosystem and you will learn to take advantage of it in your everyday development tasks. Come and see how this great new addition to the .NET family makes your development process faster, clearer and happier
(Be prepared for mind-blowing demos!)
When: June 18th, 13:40
Title: Riding IronRuby on Rails
Abstract:
The most famous Ruby–driven framework is, by far, Ruby on Rails. With IronRuby, .NET developers can now take advantage of this incredible web framework without leaving their comfort zone. In this session, Shay Friedman will build an entire Web 2.0 site from scratch while using and explaining the key features of Ruby on Rails.
Come and see what Ruby on Rails is all about and what's made it the success it is today.
See you there!
Shay.
- Posted by Shay Friedman on April 29, 2010
I was talking with a guy the other day about choosing ASP.NET MVC over ASP.NET web forms. I told him why I think ASP.NET MVC is better (I believe it’s the way to go if you’re a .NET web developer) and he, in turn, tried to throw at me reasons of why not use ASP.NET MVC.
This conversation is legit and it’s been going on since the very beginning of the ASP.NET MVC project. However, there are a few things which are NOT legit in this conversation.
One of them is the sentence from the title: “But you need to master HTML for that, don’t you?”. I’m sorry people, but yes, you should know HTML pretty good when developing ASP.NET MVC apps. But guess what, you should know your HTML even when developing ASP.NET web forms applications! or when developing PHP, Ruby on Rails, Django, Seaside or whatever web development framework you’re using.
If you depend on Visual Studio’s visual designer to create your application HTML markup then stop now and go learn some HTML and CSS. Designers are there to help you (even though they tend to do the opposite) and they’re not there to replace your required skills!
Being a web developer without knowing HTML is like being a carpenter without knowing the difference between screws – you can build beautiful chairs but they might break apart very quickly.
So people, arguing if ASP.NET web forms or ASP.NET MVC is the right way to go is great, but as a .NET web developer you owe yourself (and your team) to know:
- C#/VB.NET
- HTML
- JavaScript
- CSS
These are fundamentals, they are NOT nice-to-know technologies!
All the best,
Shay.
- Posted by Shay Friedman on April 29, 2010
The conference season is coming and it’s time to let you know where and when you can see and meet me!
So…
This June I’ll be speaking at the Epicenter 2010 conference, taking place on June 8th-11th in Dublin, Ireland.

The conference will be hosted in the Arts building of Trinity College, which just looks awesome:

Anyways, it’s technology we’re interested in! So I’m going to have two talks in the conference:
When: June 9th, 11:00
Title: Practical IronRuby
Abstract:
Ruby has been a home for some great innovative frameworks like Ruby on Rails, Cucumber and Rake. IronRuby version 1.0 has recently been released, unleashing the power of Ruby to the .NET world.
In this session you will get familiar with the Ruby language and its amazing ecosystem and you will learn to take advantage of it in your everyday development tasks.
Come and see how this great new addition to the .NET family makes your development process faster, clearer and happier!
(Get ready for some crazy demos here!)
When: June 10th, 15:15
Title: Ruby on Rails Vs. ASP.NET MVC
Abstract:
2010 is the year when two great web development frameworks arrive at the .NET world – ASP.NET MVC 2.0 and Ruby on Rails (via IronRuby). It is the time to get to know these frameworks and learn their advantages and disadvantages. In this session I will walk you through the good, the bad and the ugly of both frameworks providing you points to consider when coming to choose one of them.
Come and see how these two wonderful web development frameworks collide!
In addition to these talks I’ll also participate on Wednesday’s evangelist night along with Jamie Van Dyke and Julian Fitzel.
By the way, I’m staying in Dublin for a few days after the conference as well so if you’re in Dublin, let me know and we’ll go grab a pint!
See you there!
Shay.
- Posted by Shay Friedman on April 28, 2010
I came across an interesting piece of code the other day, something I didn’t even know possible in C#.
Consider the next code (which doesn’t make lots of sense, but it gets the point across):
public string Test()
{
string a;
return a = "hello";
}
What do you think will happen? what will be returned from this method?
…
……
………….
………………
So?
…
……
………….
………………
The answer is that this method will return “hello”.
Why did it happen?
When thinking more about it, this behavior is expected. It becomes very clear when reading about the assignment (=) operator on MSDN:
| "The assignment operator (=) stores the value of its right-hand operand in the storage location, property, or indexer denoted by its left-hand operand and returns the value as its result." |
To make things even simpler, think about the syntax of multiple assignments in one line – b = a = “hello”; – this is exactly the same. In the sample above I just return the value instead of assigning it to the variable b.
All the best,
Shay.
- Posted by Shay Friedman on April 27, 2010
One of the first steps I do when installing a new computer is downloading process explorer and make it replace the default Windows Task Manager.
However, with my new computer not everything went so smooth and after setting Process Explorer to replace the Task Manager, it screwed something up. After that, every time I tried to load the task manager I received the error: “Windows cannot find “C:\Windows\System32\taskmgr.exe”:
Such things can drive me crazy!
Anyway, I researched a bit and found the problem, which just like any Windows problem sourced in the registry.
So if you have the same problem, follow the next steps to solve it:
Warning: modifying the registry incorrectly can cause serious problems that may require you to reinstall Windows. Handle with care!
- Open the registry (regedit is a great tool for that).
- Go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe
- There you will find a string value named “Debugger”. This is the source of the problem and it’s probably filled with some unrecognizable string.
- If you want the default Task Manager back, set Debugger to a blank value.
- If you want to use Process Explorer as your task manager, set Debugger to the path to process explorer. For example, “c:\Utils\ProcessExplorer\procexp64.exe”.
That’s it.
All the best,
Shay.
- Posted by Shay Friedman on April 18, 2010
I understand it now, I’m just not lucky with gadgets. First it was my sound system that died on me and now my new and shiny laptop does its part in irritating me.
This morning I found out that only a month after I received it, a part of the Dell logo that resides on the top cover of the computer fell off. This is how it looks like now:
Now look, I don’t put things on my computer, I don’t throw it and I don’t scratch it. All I do is to put it in my bag and take it out of it. And it’s so upsetting that after a single month, a top-notch 2500$ computer, has this kind of flaw.
Should I expect the whole logo to fall off in the next few months?
Dell’s site says about my computer that it provides “superb performance and design”. Is this what you call “superb”?
I’m really disappointed in you, Dell. You have let me down.
Shay.
- Posted by Shay Friedman on April 9, 2010
On of the most shining features of the Ruby language for .NET developers is, in my opinion, its testing frameworks. Ruby has got such amazing testing frameworks that it is such a shame that people still use other languages to test code.
The goal of this post is simple – to show you how to test a given code in various different frameworks, so you can choose the one for you. In the meanwhile I will also take the amount of time taken for each framework to run the tests and compare the times at the end.
For that I’m using my Ruby implementation of choice – IronRuby RC4 (1.8.6 compatible) and my powerful computer (running Windows 7 64-bit). Each testing framework will contain the same 7 tests of the tested code and be executed from the command line.
Note: The testing frameworks I bring in this post are my own random picks. I tried to bring the popular ones and some other small but interesting ones. There are more testing frameworks in Ruby and if you think I should add another ones, let me know and I’ll add them to the list too.
The Tested Code
The code I’m going to test is a C# code (IronRuby FTW!) which resides in an assembly named WaterHelper.dll. The code is as follows:
namespace Demo
{
public class WaterHelper
{
public bool IsWaterBoiled(decimal celsius)
{
return celsius >= 100;
}
public bool IsWaterFrozen(decimal celsius)
{
return celsius <= 0;
}
public string GetWaterStatus(decimal celsius)
{
if (IsWaterBoiled(celsius))
{
return "Steam";
}
else if (IsWaterFrozen(celsius))
{
return "Ice";
}
return "Liquid";
}
}
}
Not much of complication here – three methods that do some water temperature related calculation.
Test::Unit
Official site: http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html
The first testing framework I’m using is Ruby’s built-in one – Test::Unit. It is very similar to NUnit (in .NET) or JUnit (in Java).
The Test::Unit test code which tests the WaterHelper class is as follows:
require 'test/unit'
require "WaterHelper.dll"
class TC_WaterHelper < Test::Unit::TestCase
def setup
@instance = Demo::WaterHelper.new
end
def test_water_boiling_point
result = @instance.is_water_boiled(100)
assert_equal true, result
end
def test_water_is_boiled
result = @instance.is_water_boiled(150)
assert_equal true, result
end
def test_water_freezing_point
result = @instance.is_water_frozen(0)
assert_equal true, result
end
def test_water_frozen
result = @instance.is_water_frozen(-50)
assert_equal true, result
end
def test_water_status_steam
result = @instance.get_water_status(300)
assert_equal "Steam", result
end
def test_water_status_liquid
result = @instance.get_water_status(70)
assert_equal "Liquid", result
end
def test_water_status_Ice
result = @instance.get_water_status(-5)
assert_equal "Ice", result
end
end
Execution time: 0.082005 seconds.
RSpec
Official site: http://rspec.info/
Version: 1.3.0
By following BDD principles and providing a clean and elegant DSL (Domain Specific language), RSpec has gained a lot of fans. It is maybe the most popular testing framework in the Ruby world currently.
The code to test the WaterHelper.dll with RSpec is as follows:
require "rubygems"
require "spec"
require "spec/autorun"
require "WaterHelper.dll"
describe "Testing WaterHelper class" do
before(:each) do
@instance = Demo::WaterHelper.new
end
it "should be boiling water when it is 100 degrees" do
result = @instance.is_water_boiled(100)
result.should be_true
end
it "should be boiling water when it is 150 degrees" do
result = @instance.is_water_boiled(150)
result.should be_true
end
it "should be frozen water when it is 0 degrees" do
result = @instance.is_water_frozen(0)
result.should be_true
end
it "should be frozen water when it is -50 degrees" do
result = @instance.is_water_frozen(-50)
result.should be_true
end
it "returns Steam for 300 degress" do
result = @instance.get_water_status(300)
result.should == "Steam"
end
it "returns Liquid for 70 degress" do
result = @instance.get_water_status(70)
result.should == "Liquid"
end
it "returns Ice for -5 degress" do
result = @instance.get_water_status(-5)
result.should == "Ice"
end
end
Execution time: 0.201012 seconds.
Cucumber
Official site: http://cukes.info/
Version: 0.6.4
Cucumber is one of the most innovative frameworks out there. It took BDD one step further by providing a simple way to write requirement documents in a language called Gherkin (which is plain English with a few rules) and interpret them via code.
The next Gherkin code contains the requirements for the WaterHelper class:
Feature: WaterHelper
As all users
I want to know the status of the water
To know how to treat it
Scenario: Water are boiled at 100 degrees
Given the temperature is 100 degrees
When I check whether the water is boiled
Then I should find out that it is
Scenario: Water are boiled at 150 degrees
Given the temperature is 150 degrees
When I check whether the water is boiled
Then I should find out that it is
Scenario: Water are frozen at 0 degrees
Given the temperature is 0 degrees
When I check whether the water is frozen
Then I should find out that it is
Scenario: Water are frozen at -50 degrees
Given the temperature is -50 degrees
When I check whether the water is frozen
Then I should find out that it is
Scenario Outline: Water status
Given the temperature is <temperature> degrees
When I check the water status
Then I should find out it is "<status>"
Examples:
| temperature | status |
| 300 | Steam |
| 70 | Liquid |
| -5 | Ice |
And this is the Ruby code file to interpret the requirements:
require "WaterHelper.dll"
Before do
@instance = Demo::WaterHelper.new
end
Given /the temperature is (.*) degrees/ do |temperature|
@temperature = temperature.to_f
end
When /I check whether the water is boiled/ do
@result = @instance.is_water_boiled(@temperature)
end
When /I check whether the water is frozen/ do
@result = @instance.is_water_frozen(@temperature)
end
When /I check the water status/ do
@result = @instance.get_water_status(@temperature)
end
Then /I should find out that it is/ do
@result.should == true
end
Then /I should find out it is "(.*)"/ do |status|
@result.should == status
end
Execution time: 0.883 seconds.
Shoulda
Official site: http://github.com/thoughtbot/shoulda
Version: 2.10.3
Modification: there is currently a bug in IronRuby which prevents Shoulda from running. I altered the IronRuby code to make it work and I’m in contact with the IronRuby team about the problem.
Shoulda is another popular testing framework. It is built on top of the Test::Unit testing framework and it makes it more developer-friendly.
The test code is as follows:
require 'rubygems'
require 'shoulda'
require "WaterHelper.dll"
class WaterHelperTest < Test::Unit::TestCase
context "WaterHelper" do
setup do
@instance = Demo::WaterHelper.new
end
should "be boiling water when it is 100 degrees" do
result = @instance.is_water_boiled(100)
assert_equal true, result
end
should "be boiling water when it is 150 degrees" do
result = @instance.is_water_boiled(150)
assert_equal true, result
end
should "be frozen water when it is 0 degrees" do
result = @instance.is_water_frozen(0)
assert_equal true, result
end
should "be frozen water when it is -50 degrees" do
result = @instance.is_water_frozen(-50)
assert_equal true, result
end
should "return Steam for 300 degress" do
result = @instance.get_water_status(300)
assert_equal "Steam", result
end
should "return Liquid for 70 degress" do
result = @instance.get_water_status(70)
assert_equal "Liquid", result
end
should "return Ice for -5 degress" do
result = @instance.get_water_status(-5)
assert_equal "Ice", result
end
end
end
Execution time: 0.096005
riot
Official site: http://github.com/thumblemonks/riot
Version: 0.10.13
Modification: changed code to use iron-term-ansicolor (IronRuby’s equivalent to term/ansicolor)
The riot testing framework is a cute little thing. Its main goal is to make it quicker to write tests and to execute them. The code turns out very minimalistic, which makes this framework a good choice when you need to write some quick unit tests.
The next code contains the unit tests for the WaterHelper class written with the riot framework:
require "rubygems"
require "riot"
require "WaterHelper.dll"
context "Tests WaterHelper class" do
setup { Demo::WaterHelper.new }
asserts("the water is boiling when it is 100 degrees") { topic.is_water_boiled(100) }
asserts("the water is boiling when it is 150 degrees") { topic.is_water_boiled(150) }
asserts("the water is frozen when it is 0 degrees") { topic.is_water_frozen(0) }
asserts("the water is frozen when it is -50 degrees") { topic.is_water_frozen(-50) }
asserts("you get steam when it is 300 degress") { topic.get_water_status(300) == "Steam" }
asserts("you get liquid when it is 70 degress") { topic.get_water_status(70) == "Liquid" }
asserts("you get ice when it is -5 degress") { topic.get_water_status(-5) == "Ice" }
end
Execution time: 0.083005 seconds.
Protest
Official site: http://rubyprotest.org/
Version: 0.3
Protest is another small and fun testing framework. It is described as a “small, simple and easy-to-extend testing framework” on its web site. It keeps it promise, I tell ya!
The next code tests the WaterHelper class using the Protest framework:
require "rubygems"
require "protest"
require "WaterHelper.dll"
Protest.context "WaterHelper class" do
setup do
@instance = Demo::WaterHelper.new
end
test "should be boiling water when it is 100 degrees" do
result = @instance.is_water_boiled(100)
assert result == true
end
test "should be boiling water when it is 150 degrees" do
result = @instance.is_water_boiled(150)
assert result == true
end
test "should be frozen water when it is 0 degrees" do
result = @instance.is_water_frozen(0)
assert result == true
end
test "should be frozen water when it is -50 degrees" do
result = @instance.is_water_frozen(-50)
assert result == true
end
test "returns Steam for 300 degress" do
result = @instance.get_water_status(300)
assert result == "Steam"
end
test "returns Liquid for 70 degress" do
result = @instance.get_water_status(70)
assert result == "Liquid"
end
test "returns Ice for -5 degress" do
result = @instance.get_water_status(-5)
assert result == "Ice"
end
end
Execution time: 0.164009 seconds.
Stories
Official site: http://github.com/citrusbyte/stories
Version: 0.1.3
The Stories testing framework is built on top of Test::Unit and provides an entire different syntax for it. It has a convenient DSL for writing tests as “stories”.
The next code tests the WaterHelper class using the Stories framework:
require "rubygems"
require "stories"
require "WaterHelper.dll"
class WaterHelperClass < Test::Unit::TestCase
story "As a user I want to know the status of the water" do
setup do
@instance = Demo::WaterHelper.new
end
scenario "Given 100 degrees, the water should be boiled" do
result = @instance.is_water_boiled(100)
assert_equal true, result
end
scenario "Given 150 degress, the water should be boiled" do
result = @instance.is_water_boiled(150)
assert_equal true, result
end
scenario "Given 0 degress, the water should be frozen" do
result = @instance.is_water_frozen(0)
assert_equal true, result
end
scenario "Given -50 degress, the water should be frozen" do
result = @instance.is_water_frozen(-50)
assert_equal true, result
end
scenario "On 300 degrees, water status should be steam" do
result = @instance.get_water_status(300)
assert_equal "Steam", result
end
scenario "On 70 degrees, water status should be liquid" do
result = @instance.get_water_status(70)
assert_equal "Liquid", result
end
scenario "On -5 degrees, water status should be ice" do
result = @instance.get_water_status(-5)
assert_equal "Ice", result
end
end
end
Execution time: 0.118007 seconds.
Lemon
Official site: http://proutils.github.com/lemon/
Version: 10.03.06
Lemon is an interesting unit testing framework. It provides a DSL which makes it very clear to identify which class and method you are testing. Moreover, it has code coverage capabilities which can report you which methods are not covered by your code. It is dependant on a bunch of other gems which makes it a bit slower than other frameworks.
The next code tests the WaterHelper class using the Lemon framework:
require "WaterHelper.dll"
TestCase Demo::WaterHelper do
Concern "Water statuses are returned as expected."
Before { @instance = Demo::WaterHelper.new }
Unit :is_water_boiled => "returns true for 100 degress" do
result = @instance.is_water_boiled(100)
result.assert == true
end
Unit :is_water_boiled => "returns true for 150 degress" do
result = @instance.is_water_boiled(150)
result.assert == true
end
Unit :is_water_frozen => "returns true for 0 degress" do
result = @instance.is_water_frozen(0)
result.assert == true
end
Unit :is_water_frozen => "returns true for -50 degress" do
result = @instance.is_water_frozen(-50)
result.assert == true
end
Unit :get_water_status => "returns Steam for 300 degress" do
result = @instance.get_water_status(300)
result.assert == "Steam"
end
Unit :get_water_status => "returns Liquid for 70 degress" do
result = @instance.get_water_status(70)
result.assert == "Liquid"
end
Unit :get_water_status => "returns Ice for -5 degress" do
result = @instance.get_water_status(-5)
result.assert == "Ice"
end
end
Execution time: 1.204097 seconds.
bacon
Official site: http://rubyforge.org/projects/test-spec
Version: 1.1
bacon is a small RSpec clone which is written in 300 lines of code. Its syntax is very similar to RSpec with a small difference on the expectation method (should).
The next code tests the WaterHelper class with the bacon framework:
require "rubygems"
require "bacon"
require "WaterHelper.dll"
describe "Testing WaterHelper class" do
before do
@instance = Demo::WaterHelper.new
end
it "should be boiling water when it is 100 degrees" do
result = @instance.is_water_boiled(100)
result.should.be.true
end
it "should be boiling water when it is 150 degrees" do
result = @instance.is_water_boiled(150)
result.should.be.true
end
it "should be frozen water when it is 0 degrees" do
result = @instance.is_water_frozen(0)
result.should.be.true
end
it "should be frozen water when it is -50 degrees" do
result = @instance.is_water_frozen(-50)
result.should.be.true
end
it "returns Steam for 300 degress" do
result = @instance.get_water_status(300)
result.should.equal "Steam"
end
it "returns Liquid for 70 degress" do
result = @instance.get_water_status(70)
result.should.equal "Liquid"
end
it "returns Ice for -5 degress" do
result = @instance.get_water_status(-5)
result.should.equal "Ice"
end
end
Execution time: 0.120007 seconds.
Contest
Official site: http://rdoc.info/projects/citrusbyte/contest and http://github.com/citrusbyte/contest
Version: 0.1.2
Contest’s target is to bring contexts to Test::Unit. Its syntax is similar to Shoulda’s just with a different test method name (named test).
The code:
require 'rubygems'
require 'contest'
require "WaterHelper.dll"
class WaterHelperTest < Test::Unit::TestCase
context "WaterHelper" do
setup do
@instance = Demo::WaterHelper.new
end
test "be boiling water when it is 100 degrees" do
result = @instance.is_water_boiled(100)
assert_equal true, result
end
test "be boiling water when it is 150 degrees" do
result = @instance.is_water_boiled(150)
assert_equal true, result
end
test "be frozen water when it is 0 degrees" do
result = @instance.is_water_frozen(0)
assert_equal true, result
end
test "be frozen water when it is -50 degrees" do
result = @instance.is_water_frozen(-50)
assert_equal true, result
end
test "return Steam for 300 degress" do
result = @instance.get_water_status(300)
assert_equal "Steam", result
end
test "return Liquid for 70 degress" do
result = @instance.get_water_status(70)
assert_equal "Liquid", result
end
test "return Ice for -5 degress" do
result = @instance.get_water_status(-5)
assert_equal "Ice", result
end
end
end
Execution time: 0.077004
Custom Testing Framework
This is a custom testing framework built in one line of code. I found it in a blog post by Paul Berry. It is not really for production purposes but it works well, it’s cool and it shows you how powerful Ruby is.
This next piece of code contains both the tests and the testing framework implementation. I surrounded everything with the Benchmark library to get the amount of time it takes to execute the tests:
require "benchmark"
require "WaterHelper.dll"
total_time = Benchmark.measure do
tests = {
"is_water_boiled(100)" => true,
"is_water_boiled(150)" => true,
"is_water_frozen(0)" => true,
"is_water_frozen(-50)" => true,
"get_water_status(300)" => "Steam",
"get_water_status(70)" => "Liquid",
"get_water_status(-5)" => "Ice"
}
instance = Demo::WaterHelper.new
# The next line goes over all tests and executes them
tests.each{|e,v| puts((r=eval("instance." + e))==v ? ". #{e}" : "! #{e} was '#{r}', expected '#{v}'")}
end
puts total_time
Execution time: 0.156001 seconds.
Benchmark Conclusion
Benchmarking testing frameworks is not such a good idea. Performance is not something you should care about when you write tests. It is much more important to have a maintainable set of tests instead of fast running ones that need a week of work when a requirement changes.
But, it’s cool and interesting to have charts in blog posts! so, here it is… the comparison between the execution time of all testing frameworks in this post:
It turned out that Contest is the quickest one but except Cucumber and Lemon, the rest of the frameworks are behind only by a small difference.
Interesting facts:
- All frameworks finished the tests under 1 second.
- Test::Unit is more than 2 times faster than RSpec.
- Contest, which is build on top of Test::Unit, actually runs a bit faster (I tried that multiple times!)
- The custom testing framework got a real nice spot in the middle.
- Cucumber is not the quickest one at all but it is still the coolest one :-)
Conclusion
IronRuby opens a whole new world of opportunities for .NET developers and Rubyists. In this post I focused on testing code but of course there is much more to it than just that. However, this showcase gets my point through – this post includes a variety of 11 (!!!) different testing frameworks. Each frameworks has its own uniqueness, making it very easy for you to choose the framework that works best for you.
And just for you to know - I had so much fun writing this post! Ruby is just awesome. Period.
All the best,
Shay.
Share: DZone | RubyFlow | Reddit
