[アーティクル]
08/28/2015

February 2009

Volume 24 Number 02

.NET との相互運用性 - IronRuby と RSpec の概要 (第 1 部)

Ben Hall | February 2009

この記事は、IronRuby のプレリリース版に基づいています。ここに記載されているすべての情報は、変更される場合があります。

この記事では、次の内容について説明します。

Ruby と Duck Typing
Ruby と Microsoft .NET Framework
IronRuby と RSpec を使用する

この記事では、次のテクノロジを使用しています。
IronRuby

コードは MSDN コードギャラリーからダウンロードできます。
オンラインでのコードの参照

コードで要件とサンプルを定義する
Ruby と Duck Typing
Ruby とメタプログラミング
Ruby と .NET Framework
Ruby と CLR
IronRuby の内部
IronRuby を使用して C# アプリケーションをテストする
今後の予定

「我々がお願いしたのはこんなものじゃありません!」。おそらくほとんどの開発者が、最新のビルドの納品直後に顧客からこのような抗議を受けたことがあるはずです。顧客が気の毒な開発者に声を荒げる理由は、要求した事柄が正しく理解されていなかった、単にシステムの一部が機能しなかったなど、さまざまです。

顧客が自身の要件を明確に把握していないことはよくありますが、そのような顧客は安全策として、システムに望むあらゆる処理を 100 ページに及ぶ技術文書で定義しようとします。一方、開発者は、アプリケーションに求められている動作を理解し、機能を損なうことなく新しい要件を実装しようとして、文書化されていないレガシコードと格闘します。

時代は変わりつつあります。ソフトウェア開発の新しいアプローチの目的は、これらの問題を解決し、開発者が工程に支障を来すことなく最初の段階から顧客の要求を満たせるように支援することです。これらのアプローチでは、開発のサイクルを大幅に短縮しつつ、読みやすく管理が容易なコードを作成できる Ruby などの言語を活用します。

この記事では、Ruby と IronRuby について紹介すると共に、Microsoft .NET Framework ベースのコードとの Ruby の相互運用性の基本を説明します。また、RSpec などのフレームワークを使用してオブジェクトの目的の動作のサンプルを生成し、その動作のドキュメントを提供する方法と、システムが適切に構築されていることを検証する方法についても説明します。次回の記事では、受け入れテストの詳細と IronRuby を使用した受け入れテストの作成方法を説明します。今回の内容を踏まえたうえでお読みください。

コードで要件とサンプルを定義する

簡単にサンプルを記述し、要件を定義できるようにするには、フレームワークが必要です。自動受け入れテストや実行可能な仕様は、さまざまな方法で記述できます。一般的な xUnit テストフレームワークをうまく利用している開発者もいれば、Fit および Fitness フレームワークを使用している開発者もいます。筆者は、振舞駆動開発 (BDD) を利用するのが最適なアプローチであると考えています。Dan North 氏の考案した JBehave と呼ばれる BDD フレームワークは、技術的知識の程度を問わず、チーム全員が理解できる形でアプリケーションの動作を示したシナリオを定義するための手段です。

JBehave は、North 氏がテスト駆動開発 (TDD) で直面した問題の解決策として生み出されたものであり、Java 言語向けに実装されています。North 氏はその後、RBehave を作成しています。RBehave は、人気の高い Ruby 向けフレームワークである RSpec に統合されています。RSpec は、BDD の 2 種類のアプローチに対応しています。アプリケーションの動作を示すストーリーとシナリオに基づく Dan North 氏のアプローチと、オブジェクトレベルでサンプルを作成することに重きを置いた Dave Astels 氏のアプローチです。

C# にも、NSpec や NBehave など、いくつかの BDD フレームワークがあります。C# でテストを記述する場合の主な問題点は、余分な構造上の要素やメタデータ (中かっこ、public、private など) があるために、テストの真の意図が見失われがちになることです。総合的に見て、C# と NSpec/NBehave の組み合わせよりも IronRuby と RSpec の方が使い勝手が良いと言えるでしょう。かねてより、C# 開発者にとってこれが大きな問題となっていました。C# アプリケーションのテストに Ruby ベースの RSpec を使用できなかったからです。しかし IronRuby があれば、この問題は解決します。

IronRuby の開発はまだ始まったばかりですが、IronRuby は動的言語ランタイム (DLR) を活用して CLR 上に Ruby 言語の実装を作成します。IronRuby を利用すると、.NET Framework と .NET 準拠の言語と共に、既存の Ruby アプリケーションとフレームワークを採用できます。その結果、Ruby 言語と RSpec を使用して C# アプリケーションをテストすることができます。

言語としての Ruby は簡潔です。そのため、記述するコードの量を抑え、コードをはるかに自然な形で表現することができます。したがって、コードの管理も簡単になります。たとえば、ファイルからすべてのテキスト行を読み取り、コンソールに書き出すには、次のように記述します。

File.readlines('AboutMicrosoft.txt').map {|line| puts line}

このコードは AboutMicrosoft.txt ファイルを開き、すべての行を読み取った後、各行をパラメータとしてブロックに渡します。その後、パラメータがコンソールに書き込まれます。Ruby におけるブロックは、中かっこに囲まれたステートメントのコレクションです。C# におけるメソッドの呼び出しに似ており、yield ステートメントを使用して呼び出し側メソッドに制御を返します。

自然言語的なアプローチが可能というのが、Ruby がテストに役立つ理由の 1 つです。Ruby を使用すると、テスト (この場合はシナリオ) が格段にわかりやすくなります。

Ruby と Duck Typing

Ruby と動的言語の方が判読しやすい理由の 1 つは、型指定の処理方法にあります。Ruby では、開発者は型を指定しません。その代わりに、コードの中断時に変数の型が推定されます。言語は依然として厳密に型指定されていますが、変数の型は動的に決定されます。

C# では、実装のコントラクトを定義しつつ、インターフェイスでオブジェクトを分離できます。Ruby の場合は、コントラクトやインターフェイスは必要ありません。オブジェクトに呼び出しているメソッドの実装がある場合は、その実装が呼び出されます。ない場合は、エラーが返されます。このように、オブジェクトのコントラクトは、コードの他の部分との関係ではなく、その実装によって定義されます。

これを具体的に示すために、筆者は値を受け取るメソッドを作成しました。その値の型は、実行時に推定されます。その後、メソッドは Hello と値を出力します。

def SayHello(val)
     puts "Hello #{val}"
end

型はこのような方法で処理されるため、コードを一切変更することなく文字列と整数の両方に同じメソッドを利用できます。

SayHello("Test") => "Hello Test"
SayHello(5) => "Hello 5"

Ruby では中かっこを省略できるため、中かっこなしでメソッドを呼び出すこともできます。こうすることで、構文が格段にわかりやすくなります。

SayHello "Test" => "Hello Test"

C# でもオブジェクトを使用して同じことが可能ですが、オブジェクトがもっと複雑な場合はどうなるかを見てみましょう。筆者は GetName の呼び出しの結果を出力する新しいメソッドを定義しました。パラメータ n の値が GetName というメソッドを実装している限り、コードは正常に機能します。

def outputName(n)
  puts n.GetName()
end

無関係な 2 つのクラスを次に示します。

class Person
  attr_accessor :name
  def GetName()
    @name
  end
end
class Product
  def GetName()
    "The product with no name"
  end
end

Person には name 変数を設定できるアクセサがあります。一方、Product はハードコーディングされた値を返します。Ruby では return ステートメントを記述する必要がありません。既定では、メソッドのコードの最終行の最後の結果が返されます。

outputName メソッドを呼び出すと GetName メソッドが呼び出されます。このことから、Ruby の型指定ではメソッドが単一の型に縛られないため、コードの再利用性が高まるということがわかります。

outputName(Product.new) => "The product with no name"
$x = Person.new
$x.name = "Ben Hall"
outputName($x) => "Ben Hall"

GetName を実装していない引数を使用してメソッドを呼び出すと、NoMethodError が生成されます。

outputName("MyName") => :1:in 'outputName': \
  undefined method 'GetName' \
  for MyName:String (NoMethodError)

この概念に一部の開発者はとまどうかもしれませんが、テストの容易性を高め、アプリケーションのデザインを改善できるため、覚えておいて損はありません。特に C# アプリケーションをテストする場合に役立つ概念です。この内容については、次のセクションで説明します。

Ruby とメタプログラミング

他の動的言語と同じように、Ruby にもメタプログラミングの概念が取り入れられています。そのため、実行時に任意のクラスやオブジェクトを拡張したり、メソッドと動作を実行時に定義したりできます。また、自己書き換えアプリケーションの開発も可能になります。これは動的言語において非常に役立ち、特に単体テストを作成する場合に有用です。独自の要件に合わせてオブジェクトとメソッドの動作をカスタマイズできるためです。

同様の方法で、組み込みの Ruby クラスを拡張し、C# 3.0 の拡張メソッドとよく似た独自の機能を提供できます。C# の場合は、作成できるメソッドについてさまざまな制限が課されます。たとえば、作成できるのは個別のクラスに含まれる静的メソッドに限られます。こうした制限のため、可読性が損なわれます。Ruby の場合は、既存のクラスに通常のメソッドを作成します。整数を処理する Integer というクラスを例に考えてみましょう。Integer には一連のメソッドがありますが、数値が偶数かどうかを判断するメソッドはありません。

このようなメソッドを作成する場合は、同じ名前 (Integer) のクラスを新たに作成し、新しいメソッドを定義してください。判読しやすくするために、メソッド末尾には Boolean 値を返すことを示す疑問符が追加されています。

class Integer
   def even?()
       self.abs % 2 == 0
   end
end
puts 2.even? => true
puts 1.even? => false

Ruby と .NET Framework

IronRuby を利用するとジョブに最適な言語を使用できるため、静的言語と動的言語のどちらを使用すべきかというありがちな議論を行う必要がなくなります。C# の方が適している場合は、C# を使用できます。より動的なアプローチをとる必要がある場合には簡単に IronRuby を使用でき、.NET との相互運用性や Ruby 言語の動的な性質を活かすことができます。主要なアプリケーションには C#、テストには Ruby という具合に、異なる言語とテクノロジを組み合わせて使用することをお勧めします。

DLR は、.NET との相互運用を可能にするための土台です。DLR があれば、Windows フォーム、Windows Presentation Foundation (WPF)、Silverlight などの UI テクノロジを活用しながら、Ruby でアプリケーションコードを記述できます。

IronRuby から WPF を利用するのはいたって簡単です。次のコードを実行すると、完全に機能する WPF ウィンドウを IronRuby から作成できます。C# の場合と同じように、require ステートメントを使用して、.NET Framework 3.0 に含まれている 2 つの WPF アセンブリと mscorlib を参照してください。

require 'mscorlib'
require 'PresentationFramework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
require 'PresentationCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

これで、WPF オブジェクトを作成し、対話できます。まず、使用するすべてのオブジェクトのエイリアスを作成します。こうすることで、オブジェクトにその名前空間を介してアクセスする必要がなくなるため、コードがすっきりします。

Window = System::Windows::Window
Application = System::Windows::Application
Button = System::Windows::Controls::Button

次に、WPF ウィンドウを作成し、タイトルを付けます。

win = Window.new
win.title = 'IronRuby and WPF Interop'

同じ方法でボタンを作成します。

mainButton = Button.new
mainButton.content = "I'm a WPF button — press me"

どちらのインスタンスでも、オブジェクトの完全な名前にアクセスするためにエイリアスを使用しています。ここでは、ボタンがクリックされたときにユーザーにメッセージボックスを表示することにします。C# の場合と同様にイベントをサブスクライブし、クリックイベントが発生したときに呼び出されるブロックを提供できます。

mainButton.click do |sender, args|
  System::Windows::MessageBox.Show("Created using IronRuby!")
end

最後に、ウィンドウのコンテンツをボタンとして設定し、新しい Application オブジェクトを作成してから、ウィンドウを起動します。

win.content = mainButton
my_app = Application.new
my_app.run win

図 1 IronRuby を使用して WPF アプリケーションを作成する

これで、正しく関連付けられているクリックイベントが発生すると、図 1 に示す完全にインタラクティブな WPF ウィンドウが表示されるようになりました。ここでは、Ruby ライブラリと対話するときと同じ方法で .NET Framework と対話しています。John Lam 氏とチームが主張する基本的なプリンシパルの 1 つは、Ruby 言語に忠実であれということです。これは、IronRuby への移行だけを理由に Ruby アプリケーションの作成方法までは変えたくないと考える昨今の Ruby 開発者にとって、大歓迎のプリンシパルです。リッチなすべての .NET コードに同じ方法でアクセスすることができます。

Ruby と CLR

ここでもう 1 つ例を紹介します。IEnumerable の AddRange にアクセスする場合、C# のコードは次のようになります。

ArrayList list = new ArrayList();
list.AddRange(new [] { 1,2,3,4 });

ただし Ruby では、可読性を高めるために、メソッド名の中の単語をアンダースコアで分けるという規則が一般に認められています。この規則に従うために別のライブラリを作成するのは、時間がかかりすぎるうえ、間違いの元です。サードパーティの開発作業の助けにもなりません。

そこで、CLR オブジェクトの場合、IronRuby は Ruby のメソッド呼び出しを CLR 用の同等のメソッド名に変換します。

$list = ArrayList.new
$list.add_range([1,2,3,4])

ここでは、Ruby のアプローチに沿って AddRange メソッドにアクセスしています。メソッド名は小文字で表され、単語はアンダースコアで区切られています。CLR の名前付け規則に従って、Ruby でメソッド名を残してもかまいません。

$list.AddRange([1,2,3,4])

どちらのパターンも同じように機能します。どちらを使うかは、個人の好みです。

既に説明したように、Ruby ではオブジェクトの型を実行時に推定します。これは C# オブジェクトを処理するときも同じです。異なる型のオブジェクトを返す一連の C# メソッドについて考えてみましょう。同じオブジェクトが返されるとき、メソッドシグネチャはインターフェイスか具象型を返します。筆者の例には、単一の HelloWorld メソッドを定義するインターフェイスがあります。

public interface IHello {
  string HelloWorld();    
}

筆者は、Hello3Times から継承する Hello4Times クラスを作成しました。Hello3Times はインターフェイスから継承しますが、さらに 3 つの HelloWorld メソッドを実装しています。このクラスに、基本の実装を呼び出す HelloMethodOn4Times という新しいメソッドを定義します。

public class Hello4Times : Hello3Times {
  public string HelloMethodOn4Times () {
    return base.HelloWorld();
  }
}

次に、Hello4Times クラスの新しいインスタンスを返す (ただし、インターフェイスとして呼び出し側のコードに返す) メソッドと静的クラスを作成します。この場合、呼び出し側のコードは HelloWorld だけを認識すればよく、定義されている追加のメソッドを認識する必要はありません。

public static class HelloWorld {
  public static IHello ReturnHello4TimesAsInterface() {
    return new Hello4Times();
  }
}

筆者の Ruby コードには、メソッドの呼び出しが 2 つあります。最初の呼び出しの対象は、インターフェイスで定義されているメソッドです。これには問題がないように思われます。ただし、2 つ目の呼び出しの対象は具象クラスのメソッドです。IronRuby は返されるオブジェクトの型を特定しており、メソッド呼び出しをディスパッチできます。

puts InteropSample::HelloWorld.ReturnHello4TimesAsInterface.HelloWorld
puts interopSample::HelloWorld.ReturnHello4TimesAsInterface.HelloMethodOn4Times

これらの処理はすべて正常に行われます。メソッドを呼び出すためにオブジェクトを適切な型にキャストする処理を気にかける必要はありません。

次のテーマに進みましょう。.NET オブジェクトも、Ruby オブジェクトを拡張するのとまったく同じ方法で拡張できます。ここでは、メッセージボックスを表示する際に使用するアイコンやボタンは指定しません。その代わりに、メッセージを指定します。

シームレスな対話のために、組み込みの機能を使用する代わりに実際の MessageBox クラスを拡張する必要がある場合もあるでしょう。Ruby を使用すれば、こうした作業は簡単です。WPF の組み込みの MessageBox と同じクラスを新たに定義してください。次に、さまざまな既定値を持つ show メソッドを呼び出す新しいメソッドを、そのクラスに作成します。

class System::Windows::MessageBox
  def self.ShowMessage(msg)
    System::Windows::MessageBox.Show(msg, msg, \
      System::Windows::MessageBoxButton.OK, \
      System::Windows::MessageBoxImage.Stop)
  end
end

コードの次のブロックを実行すると、

System::Windows::MessageBox.ShowMessage( \ "I'm going to show you a message")

ShowMessage メソッドを呼び出すことができます。その結果、図 2 のメッセージボックスが表示されます。

図 2 Ruby でカスタムのメッセージボックスを表示する

IronRuby の内部

何が相互運用を可能にするのでしょうか。その答えは DLR です。大まかに言うと、IronRuby を使用して Ruby コードを実行すると、背後で多数の処理が行われます。まず、記述したコードが IronRuby エンジンによってトークン化され、解析されます。次に、解析されたコードが DLR の抽象構文ツリー (AST) に変換されます。これは標準化された AST です。コードを実行するためには、IronPython を初めとするすべての言語実装でこれを DLR に提供する必要があります。

DLR に AST が提供されると、DLR はツリーを中間言語 (IL) に変換します。CLR 用の汎用言語を提供するために、すべての .NET コードが IL にコンパイルされます。このようなしくみで IronRuby と .NET Framework 間の相互運用性が確保されます。その背後では、すべてのコードが IL 命令として実行されているのです。DLR は変換を終えると、IL を実行するために CLR に渡します。そして結果が IronRuby に返されます。

このプロセスでは、パフォーマンスと信頼性を高めるためにキャッシュなどの追加の処理が行われます。その詳細については、MSDN Magazine の 2007 年 10 月号に掲載されている Bill Chiles の「CLR 徹底解剖」コラム (「IronPython と動的言語ランタイム」) を参照してください。

個別のアセンブリにはホスティング API が含まれています。これによって、自分のアプリケーションに IronRuby を組み込み、C# から Ruby コードを実行したり、ユーザー独自のコードを実行したりできます。

IronRuby の実装の詳細を確認するには、RubyForge からソースコード全体をダウンロードしてください。IronRuby は C# で実装されたオープンソースプロジェクトであり、動的言語の実装の好例です。IronPython は、オープンソースプロジェクトとして CodePlex にホストされています。DLR の動作のしくみを大まかに確認するには、IronPython をダウンロードし、用意されている ToyScript というサンプル言語を試してみてください。

コア Ruby プラットフォームとの互換性を維持し続けるため、IronRuby チームは RubySpec を使用しています。これは、Ruby 言語の適切な実装方法に基づくサンプルの共有セットです。RubySpec は、Matz の Ruby Interpreter (MRI)、JRuby、MacRuby、IronRuby など、さまざまな実装の動作を統一するために利用されています。RubySpec では、MSpec という RSpec の構文互換バージョンを使用します。こうした取り組みは、IronRuby の実装の受け入れテストと見なされています。

IronRuby を使用して C# アプリケーションをテストする

何年も前から TDD はソフトウェアの開発手法として注目され、利用される場面が増えてきています。その結果、デザインと保守性の点で優れたコードが記述されるようになり、バグの数も抑えられています。IronRuby を利用すると、TDD ではなく BDD のアプローチに沿って RSpec 仕様フレームワークとランナーを使用し、C# オブジェクトの動作のサンプルを提供できます。

シナリオフレームワークは、アプリケーションレベルでの受け入れテスト向けに調整されています (シナリオフレームワークについては、今後の記事で取り上げる予定です)。一方、仕様フレームワークは、実装するコードの独自の仕様と、その目的の動作を記述する開発者向けに調整されています。仕様フレームワークは、オブジェクトレベルでの動作を示すサンプルを提供することに重点を置いて構築されています。こうしたサンプルを実行すると、システムの実装が開発者の期待どおりに動作していることを検証すると共に、オブジェクトの目的の動作を示したドキュメントを提供することができます。

これが、NUnit や MbUnit などの単体テストフレームワークとの重要な違いです。これらのフレームワークでは、テスト属性を使用してメソッドがシステムのテストであることを示します。RSpec でのアプローチは異なります。RSpec では、各メソッドがコードの目的の動作のサンプルであることを示します。些細な違いですが、これによって、使用する用語、メソッドの編成方法、TDD と比べたときの概念の理解のしやすさなど、サンプルの記述方法が変わってきます。密接に統合された IronRuby と .NET Framework、BDD、そして RSpec が揃うと、IronRuby を使用した C# アプリケーションのテストに着手できます。有名な RSpec の例に、ボウリング (Bowling) ゲームのプログラムがあります。これを利用して考えてみましょう。

まず、C# アセンブリ内のボウリングゲームの実装にアクセスする必要があります。

require File.dirname(__FILE__) + \ '/InteropSamples/Bowling/Bowling/bin/Debug/bowling.dll'

次に、RSpec にアクセスしてください。

require 'rubygems'
require 'spec'

この時点で、サンプルの記述を開始できます。これは、ボウリングの実装の目的の動作を示すサンプルです。RSpec は、サンプルを実行可能にするために使用する必要のあるドメイン固有言語 (DSL) を提供します。DSL の最初の部分は describe ブロックです。ここでは単純に、"説明" するオブジェクトをオプションの説明と共に記述します。この場合は、C# で実装する Bowling オブジェクトを定義します。

describe Bowling, " defines the bowling game" do

判読しやすくするために、セットアップは before ブロックで実行します。

before(:each) do  
    @bowling = Bowling.new 
End

この段階まできたら、オブジェクトと対話し、サンプルを作成して、正しく動作するかどうかを確認します。"it" ブロックを使用して、サンプルのコンテキストとその具体的な内容を示す文字列を指定します。次に、システムと対話するコードのセクションを記述し、動作が適切かどうかを確認します。

it "should score 0 for a gutter game" do
    20.times { @bowling.hit(0) }
    @bowling.score.should == 0
  end
end

C# の実装は、単純に次のようになります。

public class Bowling {
  public int Score { get; set; }
  public void Hit(int pins)
    { Score += pins; }
}

最後にこれを実行し、C# オブジェクトをテストする RSpec でボウリングのサンプルが期待どおりに動作することを確認します。

>ir bowling_spec.rb
.
Finished in 1.0458315 seconds
1 example, 0 failures

より詳細なレポートが必要な場合は、specdoc 形式を選択できます。この場合、すべてのサンプルとオブジェクトの説明が出力され、テストの結果が示されます。

>ir bowling_spec.rb --format specdoc
Bowling defines the bowling game
- should score 0 for a gutter game
Finished in 1.43728 seconds
1 example, 0 failures

この記事の執筆時点では、IronRuby チームによるバイナリの定期的なリリースは行われていません。チームによると、実装、互換性、パフォーマンスが満足のいくレベルに達してから公式のバイナリをリリースするとのことです。ただし、ソースコードは自由に利用できるので、コードをダウンロードして自分でビルドできます。

ソースコードをダウンロードするには、msysgit などの Git ソース管理クライアントをインストールする必要があります。IronRuby ソース管理はオンラインで提供されています。詳細については、IronRuby プロジェクトサイトか、筆者のブログ記事「Downloading IronRuby from GitHub (GitHub から IronRuby をダウンロードする)」を参照してください。ソースコードをダウンロードしたら、Visual Studio で IronRuby.sln ソリューションファイルを使用してアセンブリをコンパイルできます。また、MRI をインストールしている場合は、次のコマンドでコンパイルできます。

rake compile

IronRuby をコンパイルしたら、RSpec などの各種ライブラリをダウンロードして、追加機能を入手してください。Ruby には RubyGems の概念が取り入れられています。"gem" とは、機能や追加の依存関係をダウンロードして入手できるパッケージのことです。RSpec をダウンロードするには、コマンドプロンプトで次のコマンドを入力します。

gem install rspec

これで、Ruby コードから RSpec ライブラリにアクセスできるようになりました。ただし本稿執筆時点では、1 つか 2 つのバグのため、RSpec と IronRuby を組み合わせて使用することができません。この記事が公開されるまでにこの問題が解消されていることを望みます。RSpec のサポートの状態を確認するには、RSpec の Web サイトか IronRuby のメーリングリストを参照してください。

バグが修正されていない場合に備えて、バグを修正したバイナリと RSpec ライブラリを準備しました (注 : チームによって問題が修正されている場合は、このバージョンは使用しないでください)。

適切なバイナリを入手したら、IronRuby インタープリタである ir.exe を使用して、コードを実行できます。単純にコマンドラインからアプリケーションを起動する場合は、対話型コンソールを入力します。Ruby ではコードは行単位で実行されるため、学習やデバッグが簡単です。また、短いコマンドを実行して日常の問題を解決することができます。ファイル名をパラメータとして指定した場合は、ファイルが実行され、結果がコンソールに出力されます。

今後の予定

次回の記事では、受け入れテストの概念と、受け入れテストを活用して顧客と開発者の意思疎通を改善する方法について説明します。また、IronRuby と RSpec を使用して受け入れテストを自動化し、.NET アプリケーションを検証する方法と、システムの実行可能な仕様を作成する方法を紹介します。

Ben Hall は、コードの記述を愛し、ソフトウェア開発に並々ならぬ情熱を抱いている C# 開発者/テスタです。英国の Red Gate Software 社にテストエンジニアとして勤務し、手動、自動を問わず、ソフトウェアテストのさまざまな手法を模索しています。特に力を入れているのは、種類の異なるアプリケーションの最適なテスト手法の研究です。Ben は C# MVP です。彼のブログは Blog.BenHall.me.uk で読むことができます。

.NET との相互運用性 - IronRuby と RSpec の概要 (第 1 部)

その他のリソース