気軽にコードを動かすことができ、細かいところのテストができる。なんといってもその後の修正に対するデグレ防止にもなる。そんな便利なものではありますが、これをうまく活用してシステム開発・運用をしている現場は、あまり見かけません。他の人にもこの話題をよくふりますが、「うーん、ちょっと書いてるけどね」「いままでまったく見たことないです」答えは様々ですが、少なくとも活用されている現場の話は「多く」は聞こえてきません。テストコードのコストそこに常にあるテーマとして...「テストコードをたくさん書くと仕様変更時の修正コストが高い」もう一つ大事で根本的なテーマ...「そもそもテストコードを書くコストが高い」どちらも無視できない大きな「足かせ」です。リーン・スタートアップ、インクリメンタル開発なサービス開発では、前者のコストは大きくのしかかります。運用のしやすさ加減まず大前提を自分の経験則から。うまく活用している現場と、していない現場では、結合テストのときの「火の吹かなさ加減」と、その後の「運用のしやすさ加減」が格段に違います。運用後の変更に対するスピードが大きく異なります。結局、作ってからの変更って、とにかくデグレが怖いんですね。それなりのテストをしないといけないのですが、現実的にはテストする時間があまりないでしょう。リスクを背負って前に進むわけですが、つまづくこともあるでしょう。自動テスト実行で全てをまかなえるわけではありませんが、それでも多くの確認作業を省くことができます。変更のない業務なら別にいいかって感じですが、最近「変更のない業務」ってあまり少ないように思えます。変更の多い業務でテストコードを書きすぎると、修正コストが高い、という矛盾も常にそばに存在します。ここでいう「うまく活用している現場」とは、先ほどの「テーマ」をクリアしている場合に限るでしょう。カバレッジは100%を目指さない。定型的なテストしか書かない。このプロジェクトに合ったテストコードを書く土台を作った共通部品は、それなりに書きます。共通部品を作る人は、テストコードを書くのにもなれているのでスピードも出ます。共通部品がバグっていると、プログラマのデバッグスピードは極端に下がります。共通部品はしっかり堅く。画面は、リクエストを受け付けるエントリポイントのメソッド、PageクラスやActionクラスのpublicメソッドたち、これらを叩くテストしか書きませんでした。そのメソッドを叩く、それだけ。その結果、クラスの状態(リスポンスの関わる変数たち)が、どのようになっているかをアサート。エントリポイントから、DBまで一気通貫で動作させます。テストデータはきっちりと揃えます(ここ重要、大変だけど)。アサートは計算ではなく、ベタに期待値をハードコード。これをやるにはデータは綺麗にしていないと。単体テストって感じよりかは、クラス結合テストって感じかな。定型的なテストだけに絞る。モックは使わず、データさえ整備されていれば書けるテストに注力。いったテストを書くための土台もしっかり整備。テストのためのユーティリティを多く準備。そのプロジェクト専用のメソッドとかなどなど。「これだけは書いて!」という感じで、プログラマに横展開して実装してもらって、先ほどの「テーマ」が重くのしかかるようなことはあまりなく、そのメリットをいい感じで享受できように思います。これは単なる一つの状況に対する一つのアプローチ。これが正解でもないし、ただ結果的には悪くもなかった。テストコードの自主練は?土台が整ってない、そのプロジェクトのテストポリシーが定まってない。これらは確実に足かせにはなります。テストコードを書くのに慣れてても、これがなければやはり書きづらい。そこはアーキテクトが色々考えないと。結局は、一番左右されるポイントがここ。「多くのプログラマがテストコードを書くのに慣れていない」テストコードを書くのが遅いだけでなく、「書きすぎない」のさじ加減が判断できないから。メインのコードが書けなければ、教育コストもかけるし、本人も勉強してプログラムが書けるように頑張る。テストコードが書けなくても、そこに教育コストをかけることはあまりない。プログラマ本人も「今日は家に帰ってテストコードを書く練習をしよう」という人はあまりいないんじゃないかと。現実的に、業務でテストコードをすらっと書けるプログラマが集まることはないのかなと感じています。結局、ここが足かせになるし、とても流動的なので、現実解を見つけるのがとても難しくなる要因になるのかなと。2013年頃】ここ最近は、「画面から叩くにはケース的に難しいロジック」それだけをちょこっと動作確認するために、JUnitの単体テストで書く、っていうやり方をアドバイスしています。それがやりやすいようにするための、UTFluteというJUnitの拡張モジュールも提供。DBFlute単体テストを「建設的に」利用しつつも、逆にそうやってハードルを下げて、まずは慣れ親しんでもらうようにと。リーン・スタートアップの開発では、それが限界とも言えるかもしれません。あと、DBFluteハンズオンでは、エクササイズを単体テスト形式でやって、DBFlute学びつつ自然とテストコード実装も学べるように、っていう風になるように。jflute流の一つのアプローチです。「費用対効果の高い横断的なテスト」を現場で推し進めています。そのプロジェクトで使わないと決めた機能やメソッドを使ってないことなどなど。プロジェクト独自ルールのチェックスタイルみたいな感じですね。使って単体テストで書きます。UTFluteでいろいろこういうテストであれば、わりと効果が高いので導入しやすいかと。業務よりなロジックで書けるようになったらさらにいいかなと。現場のプログラマーは喜んでくれていますし、jfluteが書いた土台を元に、新たなテストコードを書いてくれています。DB2にも対応している国産O/RマッパーのDBFluteがついにv1.0...2012-09-15DBFlute、魂の1.0ポリシーこのように考えています。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。