テストコードのリファクタリング - ひげろぐ
TDDBC 福岡2でのTDDの失敗ケースとは何かという質疑応答から。 テストコードにもリファクタリングが必要 昔はテストコードがメンテ対象であるという意識が薄かった 見てすぐ分かるテストコードがよいという考えからコピペコードが非常に多かった テストコードがたくさんあることによって動きが取りづらくなり、変更コストも上がる 素早く動きたいがためにTDDしているのにそんな皮肉な結果になってしまう たくさん書くのではなく必要十分書くことが大切 書き散らすと「テストケース爆発」を起こす テストコードもメンテし続けるためにリファクタリングして行く必要がある テストコードもプロダクトコードと同じようにテストのGreenの状態が維持されていることで、既存のコードが壊れないことを保証しつつリファクタリングしていくことができる。 （ただしテストが無条件でオールグリーンになるみたいな酷い壊し方をしてしまう心配は
なぜリファクタリングは必要なのか？
今回からいよいよコードの話を始めます。もはやRubyの文化の一部だという主張もあるリファクタリング、テストについて、その意義や概要を紹介します 実際のアプリを例に解説 連載のこれまでは、私の過去の体験や仕事環境についてお話ししてきましたがそろそろ少しコードの話をしましょう。 これからしばらくはテストとリファクタリングがメインです。ただ理論を説明するだけでなく、実際に書かれたアプリのコードをレビューし、テストを追加しながら改善していきます。今回から解説する一連のリファクタリング、テストのターゲットは、＠IT編集部の西村賢さんがRuby on Railsで開発中の力作、「Worklista」です。 テストを書かずばRailsエンジニアにあらず？ 2010年11月に米国ニューオリンズで開催されたRubyConfでのキーノートで、Ruby on Railsの作者であるDHHは、テストについて次のよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
