Test Doubleを使うとテストの信頼性/保守性が下がるのか？ - Fly me to the Luna
最近はユニットテストを行うテストコードにおいて、Test Doubleを多用してます。Test DoubleとはMockとStubを合わせた総称です。Test Doubleを用いると、信頼性や保守性が下がると言われることがあります。しかし、それはTest Doubleの用法を誤っているためではないかと僕は思うのです。Test Doubleの用途はユニットテストのスコープをテスト対象のクラスに限定するために用いるべきものです。実感として、Test Doubleを使っているからと言って、ユニットテストの信頼性/保守性が下がったとはあまり感じていません。 良く誤解されていますが、Test Doubleはスローテスト問題を解決するための手段ではありません。Test Doubleをうまく利用すれば、結果的にスローテスト問題を解決できます。しかし、スローテスト問題を解決するための手段ではないのです。ス
次第に腐るテストコード - Fly me to the Luna
結論を最初に書くと、 テストコードを書くだけではダメで、デイリービルドなりCIしないと意味ないんじゃないっすか？という事です。 最近Hudsonを使っていてすごいいいなぁ、と思うのがこの画面。 「リグレッション」という表現はすごい的を射ているなぁ、と思います。以前は「失敗」となっていたと記憶しています。 なんで的を射ているかと思ったかと言うと、テストコードって回帰テストの中で動かされると、その結果は「成功」と「失敗」だけではありませんよね。仕様変更による影響がテストコードので、テストコードが失敗すると言う事もある訳で。確かid:hyoshiokさんのブログだったかで拝見したかなんかだったんですが、Oracleでは毎朝デベロッパが出社すると、QA担当の人から失敗した回帰テストが回覧し、デベロッパに「これは障害なのか、仕様変更による影響なのか」を判断してもらった、と言う話を目にしました。テスト
モジュラリティを考える - Fly me to the Luna
ソースコードの分かりやすさは、「単一責務の原則」と「関心毎の分離」により適切に構造を分割した、バランスのいいところにあると前のエントリに書いた。では、そこにモジュラリティが加わるとどうなるだろうか。 モジュラリティとは、システムを幾つかのモジュール*1に分離し、さらに分離したモジュールを組み合わせて新しいシステムを組むソフトウェア開発法、とここでは定義する。分かりやすい例はEclipseだ。例えばPyDevを導入すればPythonの開発環境が手に入る。このように言語環境ごとに作られたプラグインを導入すれば、それぞれの言語で開発ができるIDEが構築できる。EclipseはIDEとして必要な機能の全てをプラグインという形のモジュールに分離し、組み合わせる事でモジュラリティを実現している。*2 モジュラリティの利点と欠点を上げてみよう。 利点 モジュール毎に独立して開発できる モジュールに分割で
QCon Tokyo 2010 - Fly me to the Luna
昨年Spring Frameworkの開発者である、Rod Johnson氏やMartin Fowler氏も講演されたQCon Tokyo。今年も来る4/19、20に開催されることになりました。 参加費が2万円となる早期割引は**3月31日**までです。 これだけのスピーカーが集まるイベント自体そうそうありません。海外のカンファレンスに聞きにいくことを考えたら渡航費だけで参加費のうん倍はかかるでしょう。 今年のスピーカーはGoFのEric Gamma氏や、JCPの議長であるPatrick Curran氏、GroovyのトップコミッタのPaul King氏等々の海外のスピーカ。JGGUGの山田さん、mixiの田中洋一朗さん、Cacooの縣さんなど、そうそうたるメンバーが話します。 光栄な事に、こんぴろこと近藤も講師として参加させていただくことになりました。(下から2番めです。) OSGi以外
Mockitoノススメ テストスタイルの変化 - Fly me to the Luna
Mockitoを使うようになってから、僕はテストコードへの取り組みが変わりました。Mockitoを使うまで僕がUnit Testと思っていたものは、厳密にはUnit Testじゃないんじゃないか、と思うようになりました。なぜかというと、実装コードを書いていくと、たくさんのクラスと関連していきます。だんだんと、そのクラス、Unitをテストするのではなく、そのAPIの裏にあるクラスの状態、振る舞いも予測しなければならなくなっていきます。例えば永続化層にアクセスするクラスを開発しているのであれば、どんなに上層にあるレイヤーのクラスでも、テストデータをDBに入れないといけない、というのは、よくよく考えてみると、変な話なのです。どこかの段階で、DBを操作するクラスを参照しなくなるはずですから。大体、リズムが悪いですよね。DBの初期化用のテストデータ用意するのは大変です。 Unit Testでは、テス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
