テストでは何をテストすべきか — recompile.net
2012年08月21日 ソフトウェア開発でのテストとは何かを単純に言うと、成果物が期待通りであるかを検証する作業といえる。こう動作してほしいという期待を入力に、成果物がその通りに動作するかを検証するのがテストである。 となると、成果物とは何で、期待とは何かが問題になるのだけれど、これが一筋縄ではない。というのも、システムは十分に複雑なので、ある部分を複数の部分に分けることもできるし、その部分をより大きな部分のパーツにすぎないとみなすこともできるからだ。 だからといって、一番大きな単位でもって期待通りにあるかどうかを検証すれば済む話かというとそういうわけでもない。というのも、大きな単位には大きな単位なりの期待が、小さな単位には小さな単位なりの期待というものが存在するからだ。 システム開発は、ひとつのものさしではかることができない。システムをつかって業務を遂行できるかという検証と、その部品であ
完了条件について - tech.recompile.net
システム開発をする上で、完了条件は避けて通れない。完了条件とは、いつ仕事が終わったかを定義するものである。この仕事が完成したということをステークスホルダー間で合意できる基準といってもよい。 仕事全体の完了を示す完了条件もあれば、仕事が次のステップへと移っていいという指標になる完了条件もある。完了条件は、下位の完了条件が満たされることという完了条件もあれば、同じような大きさの完了条件が全て満たされてはじめて完了となるようなものもある。おおよそ仕事として分割できる単位であれば、完了条件があるといってもよい。それだけに、完了条件は重要である。 完了条件というと、どうも固い言葉で手戻りを許さないウォーターフォール型の開発でしか使われていないと感じる人もいるかもしれない。ところが、スクラムといったアジャイルプロセスであってもDoneの定義（＝完了条件）は重要な位置を占めている。もちろん、ウォーターフ
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
