モブプログラミングとは?
この記事では複数人で行われるプログラミングの意です。
ペアプロの延長線上だと考えて下さい。
正確な定義とは異なるかもしれません。
参考までに以前書いた記事です。
データ抽出のテストって?
何らかのデータストアに対して、クエリを発行し、結果を取得するようなUnitTestを想定しています。
MySQLようなRDBMSに、Select文を発行して結果を確認するようなイメージです。
データ抽出のテストの何が問題なの?
データ抽出のテストは実装後のレビューコストが高いです。
データ抽出する処理の実装時に考慮すべきことに例えば下記があると思います。
- データストアの設計
- RDBMSでいうER。オブジェクト間のリレーション。仕様的なものも含む
- データ
- どんなテーブルに、どんなデータが入っているか
- クエリの構造
- JOIN句の類。内部結合か外部結合か。UNIONやソート順などなど
- パラメータ
- どんな条件で検索するか。SelectでいうWhere句
- etc
多くの場合、実装者はこれらを並行で考慮しながらテストを書く必要があります。
そして、主にデータパターンとパラメータの組み合わせでテストの意図が込められていきます。
意図の読み解きが難しい
データパターンやパラメータの場合、コードから意図を読み解くことは一般的に難しいと思います。
レビュワーも当然前述の項目を並行で考えなければならないからです。
ケースは思い浮かんでも、どこで実施しているかを読み解くのは困難です。
DbSetupのようにテストデータの可視性を高めるライブラリもありますが、限界はあります。
そのため、後からコードレビューを行う際に、どうしてもコストが高くなってしまうのです。
なぜモブプログラミングがよいの?
モブプログラミングではリアルタイムでレビューを行います。
そのため、ドライバーが意図を説明しながら、ナビゲーターが意図を理解しながら同時進行で進めることができます。
なので、実装とレビューでフェーズを分ける場合に比べて効率が格段に上がると思います。
僕らはさらに、着手前にチームメンバーで想定されるテストケースの洗い出しをしました。
作業を進めていく中で、実はいらなかったケースなどが出てきたりして、とても効果的だったと思います。
まとめ
性質上、コードから意図の読み取りが難しくなるような場合は、モブプログラミングをおすすめします。
モブプログラミング楽しいですよ、モブプロ。
みんなでテストケースを洗い出すの図