2011-12-10 6 views
4

私はちょうどTails with Railsに入っています。私に困惑しているのは「テストを書くとき」です。すべてのガイドは、コードを記述する前にテストを書くべきだが、Personモデルを作成してから、コードを書く前に次のテストを書くことをお勧めします。Rails TDD - 最初に書き込むもの

p = Person.new 
p.firstname = "mikey" 
p.lastname = "hogarth" 
assert_equal p.fullname, "mikey hogarth" 

次に、テスト自体は失敗しません、それはクラッシュします!私はまだ "fullname"メソッドを実装していないので、ランタイムエラーが発生します。したがって、コードを書くまで、私はおそらくそのテストを失敗させることはできません。

TDDコーダーは、通常どのようにこのような状況に近づいていますか?それは基本的にダミーのメソッドスタブであるか、それとも良い方法ですか?

===編集===素晴らしいアイデアの

多くが示唆されました。私は最終的に次の選択肢が私が最も優雅にやろうとしていたことを達成することを決めました。

if p.respond_to? "fullname" 
    assert_equal "Mikey Hogarth", p.fullname 
else 
    flunk "fullname not implemented" 
end 

=== SECOND EDIT ===

あなたはこの答えに遭遇した場合、上記のコードが動作するしばらくので、それは良い習慣ではない、TDDへの私の全体的なアプローチが問題だったようです。

+0

なぜp.fullnameが定義されているかテストしないでください。 – prusswan

+0

私はそれがこのようなものかもしれないと思った、私はこの種の構文で遊んでいた。 p = Person.new; methods =%q {name firstname fullname}; methods.each {|メソッド| p.respond_toをアサートしますか?方法 }。 これは一般的に人々がどのように行うのでしょうか? –

+0

@MikeyHogarth私はあなたが例でケントベックのテスト駆動開発を手に入れることをお勧めします。 Javaを使用していますが、本の概念はどの言語にも当てはまります。それはTDDの "Hello World"の本と考えられています。 http://www.amazon.co.uk/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530 – Finglas

答えて

3

あなたが望むコードを書いてください。 Cスタイルの言語/静的にコンパイルされた言語では、コードが存在しないと正しく書いたので、上記はコンパイルされません。これは問題ありません。テストを実行するには、コードをビルドするための最小限の実装が必要です。言い換えれば、あなたのテストはあなたのデザインを推進します。

Rubyは非常に錆びていますが、上記の例では存在しないメソッド/プロパティに対してmethod_missingの行に沿ったものがスローされます。したがって、それらを作成します。

class Person 
    attr_accessor :firstname, :lastname 

    def fullname 

    end 
end 

あなたが今、あなたのテストを実行する場合は、nilをフルネームから返されます。したがって、fullnameメソッドを実装します。ここで留意すべき点は、メソッドが欠落しているというRubyの発話ではなく、メッセージが変更されていることです。メソッドが正しく実装されていないことがテストで分かりました。

def fullname 
    return @firstname + " " + @lastname 
end 

これでテストに合格します。

基本的には、実行後に表示されるメッセージを変更する(これはあなたがどこかにいることを証明する)か、それを通過させたいかのどちらかです。テストが合格したら、リファクタリングすることができます。上記の方法は簡単ですが、return文を削除したり、文字列の書式設定などを使用することができます。テストが終わる限り、あなたは良いことが分かっています。

+0

@surnameまたは@lastname? – buruzaemon

+0

私はダミーメソッドを書くことになると思っていました。 –

+0

私が言ったように、私のRuby/Railsは弱いですが、Corey HainesはあなたのRubyコードからRailsを抽象化する方法について素晴らしい話をしています。前述のモデルがActiveRecordに依存しているかのように、あなたのアプローチを若干変更する必要があるかもしれません。 http://confreaks.net/videos/641-gogaruco2011-fast-rails-tests – Finglas

1

これらの状況でテストコードがクラッシュすることは問題ありません。それを失敗として考えてください。

実際のコードの前にテストコードを書くと、実際にこのクラスの実装を開始する前に、テスト対象のクラスのインターフェイスを設計できるようになります。クラスの使用例がありますが、それは素晴らしいです!

この後、テスト中の実際のクラスを作成する必要があります。テストは失敗し、クラッシュしません。そして、このテストをパスし、リファクタリングし、失敗したテストを続けます。

+0

+1クラッシュテスト*は失敗したテストです。あなたはうまくやっています。 TDDでは、まずテストを書く必要があります。 –

0

私のアプローチは、そのテストにp.fullname.nil?という条件付きチェックを使用するか、または単に先のテストとしてassert_not_nil(p.fullname)を使用して、残りのテストが実行されないようにすることです。

+0

これでもNoMethodランタイムクラッシュが発生します。これは避けようとしているものです –

+0

あなたの提案は正しい方向に私を得ました - これはあなたが助けてくれた間に私が何をしたかを示すためにOP30を編集しました –

+0

@MikeyHogarthこれはTDDではなく、実際これはかなり恐ろしい方法です。アサートする必要があるものを決めるためにカスタムロジックを書く必要はありません。 – Finglas

関連する問題