圧倒的生産性を生み出すテスト技法

[LONERさん]

昨日レバレジーズのヒカラボへ行ってきました。「圧倒的生産性を生み出すテスト技法」ってことで、テスト自動化の話かなーと思って聞きに行きました。
実際は、テスト自動化に集中した話ではなく、折田 武己 さんというものすごい人がものすごいことをしゃべっていました。
折田さんは、テストで使用するデータを動的に生成する仕組みを作ったのでした。しかもその仕組みは、データベースのスキーマ情報が変わっても、一つのファイルを変更するだけですぐに対応できるものです。
折田さんという人はどのような人かというと、いろんな企業からの依頼を非常に高い金額で受注している方です。基本的に依頼側企業はレバレジーズに依頼して、レバレジーズが開発者を選んでアサインするのですが、折田さんの場合は「折田さんでおねがいします」っていう直接の指名がレバレジーズに来ることがあるそうです。
（そして歴史に詳しい。）
折田さんのテストデータの仕組みはこんな感じ。プロジェクトの関係上、JSONで作ったとか。データの基本ファイル、データベースへのマッピング、特定のデータをINSERTする定義ファイル（データセットファイル）、実行スクリプトの４つのファイルで構成されています。

// 基本ファイル
user {
id: "1100@users",
name: "テスト 太郎",
memo: "a,b,c"
}


// マッピング
// スキーマ変更があった場合はこれだけ変更。
user {
id: simple DB_NAME@TABLE_NAME.COLUMN_NAME,
name: ...,
memo: multiple DB_NAME@TABLE_NAME.COLUMN_NAME,
}


// データセット
INIT {
@import ロードしたいデータのID
@import ロードしたいデータのID
}
PATCH {
"データを更新するためのアップデート処理など"
}


// 実行ファイル
setup() {
// デフォルトで必要な処理
load ...
}
void テストシナリオ() {
load シナリオごとのデータ
}

書き写したのが間違っているかもしれませんが・・・こんな感じです。ちなみに今は、このデータ作成の仕組みをもっと別の書き方に変えようと尽力されているとのこと。だからもうしばらくしたらもっとすごいものができるはずです。
以下が私のメモでし。


情報ブローカーになっていない？
求められるのは問題解決能力
テストの自動化なんて当たり前でしょ？
ローマは一日にしてならず
いったい誰のためのテストなのか？


1．情報ブローカーになっていない？
フリーランス:
特定の企業や団体に専従しておらず、自らの才能や技術を提供することにより社会的に独立した個人事業主もしくは個人法人


新しい技術は日進月歩。新技術を吸収することは必須だが・・・
自動テストのフレームワークはたくさんあるが、Google で検索できなかったとき・・・あなたの考えた付加価値はなにか？
検索して情報を伝えるだけのブローカーになっても仕方ない。それよりも、成熟・安定した技術だけを利用するようにしたほうがよっぽど楽。

エンジニアが気に入るものは残念な結果になることが多い。技術者として正しい技術が生き残るとは限らない。新しいものには面白味があるが、そこにコミットしすぎると本末転倒。
コミットしているプロジェクトの問題解決をメインにするべき。

2. 求められるのは問題解決能力
SVN から git に変えたところで・・・すごいものができるわけではない。
git は後から出てきたので、機能的に優れているのは当然ともいえる。

新しい技術は書籍が出た段階で読めば十分。



テストデータはテストデータを見た瞬間にその属性がわからないといけない。
assert で説明を書くこともあるが、テストデータはテストデータとわかるように書くべき。

テストデータを「１ばん」「２ばん」としてみる
「２ばん」が「１ばん」より先に表示されたら、人間の目で見て、「ソートがおかしい」などの見当をつけることができる。

3. テストの自動化なんて当たり前でしょ？

テストコードは出来レース。
自動テストは自分が本来テストしやすいところをテストしているに過ぎない。

テストの条件として、カバレッジを挙げた場合・・・
try catch をつかって数字としてのカバレッジを達成する人が出てくる。目的が変わってくる。

単体テストのデータは開発者自身が書く場合が多い。テストファーストの場合も、そうでない場合も。
単体テストと結合テストでは調査するパターンが異なる。
単体テストでは、正常系、異常系をテストするため、バリエーションが多い。
結合テストでは、正常系のパターンを増やす。

日本のSIはだいたい論理削除を行う。この場合、論理削除後に月次の計算をすると金額が合わなかったりする。異常系のテストをしないから。物理削除をすればそんなことにはならない。

テストデータは劣化速度が速い。
スキーマ変更が入った場合、翌日にはエラーが大量に出ることがある。

単体テストと結合テストのデータを一緒に管理すると・・・
単体テストをさぼるか、膨大なデータを泣きながら管理するかに陥る。




4. ローマは一日にしてならず
ローマがほろんだ本当の理由は、インフラ整備（道の整備など）が財政を圧迫したことらしい。
= 作った後のメンテナンスがまわらない。

テストを自動化するのは簡単だが、作った後で維持・メンテナンスをするのが大変。
スクリプト、データ、リソースを別に管理する。特定のリソースに依存する部分を外に出す。ハードコーディングをしない。たとえばボタンをボタンIDで指定するなど。
そうすることでスキーマ変更などが発生しても、リソースの定義で逃げられるようになる。リソースを使って、どのテーブルのどのカラムなのかを指定する。
5. いったい誰のためのテストなのか？
多くの場合単体テストは開発者に任せられる。
単体テストデータを結合テストデータに流用することがある。
テストデータは天然ものと養殖ものがある。
テストデータに天然ものを使用すると、後で悲劇になる。スキーマ変更などが発生した場合。
天然ものはデータの精度が高いが、それを使った場合、論理削除をしてしまうとデータを元に戻せないことがある。テストデータは我々が完全に熟知しているものにするとよい。
ただ、天然ものはなんのテストにでも使える。

テストデータの劣化は避けられない。できるのはそのデータを１日でも長く延命させること。
テストデータはExcelで書くことが多いが、データをメンテナンスするのは大変。そこで、テストデータを動的に作る仕組みを作るべき。