RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
プログラマーにとってのテストの重要性
優れたエンジニアはテストコードをとても重視している、という話を本人たちから直接聞く機会が最近ありました。 オープンソース会の重鎮として知られる楽天のよしおかひろたかさんは「下手なドキュメントを書くくらいだったらテストコードを書くべきだ」「ソフトウェアはテストコードと本体のコードの両方が必要。テストコードがないのは未完成品」と、テストコードの重要性を話してくれました。「全部書き直したいような（他人の）ソースコードを見たときでも、テストを書いていると心が落ち着いてくる（笑）」（吉岡氏）。 JavaのフレームワークSeaserの開発者などで知られるひがやすを氏は、コードレビューのときに「テストコードを見る」ことがほとんどなのだそうです。「テストコードがちゃんと書けていればOK」（ひが氏）。 これは1月30日に行われた「Source Code Reading Workshop Japan 2010
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
TDD の基礎体力と、TDD に対する想い - ぐるぐる～
TDD Advent Calendar 2011 の 4 日目の参加エントリです。 前半では、TDD を学ぶ前に身に付けておくといいと思う基礎体力について書きました。 後半は、まぁ、その。後悔はしていません。反論ウェルカム、議論しようぜ。 不安をテストに 「レッド - グリーン - リファクタリング」は、TDD の根っこの部分であり、これ自体が「どう TDD をやればいいか」を教えてくれるものではありません。 それに対して、「不安をテストに」というのは、「どう TDD をやればいいか」という指針を与えてくれる言葉です。 この言葉自体は、TDD Boot Camp で自分のものにできました。 不安については、テスト駆動開発入門では (言及されているものの) 自然に組み込まれていて、最初に読んだときには全然気づきませんでした。 しかし、TDDBC で id:t-wada (和田さん) に短くて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
