何か着ていればいいよ

ソフトウェア技術者の日常や技術の話を書こうと思います。

xUnitによるUnit Test作成の心理的障壁を突破する方法

まず自分のチームでは機能開発のチケットにいちいち明記しないでもソースに対するxUnitでのカバレッジ*1を出来るだけ100%にしておく事になっており、レビューでは当然テストもレビューする形になっています。 そういったUnit Testが当たり前の状態に4-5年前からなっていて、それ以前の苦労をだいぶ忘れてきていたのですが、別のチームのプロジェクト振り返りに参加する機会があり、そのKPTなんかでxUnitのテストケースを作成するがProbremとしてあがってたりして別チームではUnit Testがなかなか出来ていないという事に気づいたのがこの記事のきっかけです。

Unit Testを作成するのに心理的な障壁がある

Unit Testを書けないと言っているそのプロジェクトメンバー何人かにヒアリングした結果 以下のような理由からUnit Testが作成出来ていないということでした。

  • Unit Testを作っている時間がない
  • Unit Testを後回しにしてしまって結局作らなかった
  • Unit Testをどう書いたら良いか分からない

ちょっと文字で列挙してしまうと伝わりづらいけれど、全体的には"やった方が良いのは分かっているけど気が重たい事"というニュアンスが伝わってくる話し振りでした。
そういった話を聞いているうちに、"そういえば、自分たちもテストを後回しにしてしまったり、気が重かったりした時期があるな"ということを思い出しました。 さらに、進んでその"気の重さ"を同克服したのかということも残しておこうと思います。

Unit Testの心理的障壁を突破するには?

上にあげたような心理的障壁が生じるにはいくつかの原因があり、それぞれについて自分のチームで効果のあった対処方法は以下の通りです。

  • xUnitについて良く知らない
    • 練習と割り切ってDTOやUtilityクラスのような依存関係の少ない超単純なクラスのメソッドからxUnitを書く
    • 上記のDTOやUtilityクラスのUnit Test作成をチケット化してこなして行く
  • Unit Testを書きづらい実装になってしまう
    • 機能を細分化してチケットにし、ペアプロやレビューを細かい単位で実施する
  • 実装を優先してしまいUnit Testがおろそかになる
    • 機能開発のチケットにはUnit Testとセットである事を明記しUnit Testが無いものはリリース基準に合致しないものとして開発完了としない
    • レビューでUnit Testの粒度や対象クラスの責任、網羅率などをチェックする

上から下に来るにつれてに経験値があがっていっているような内容になっています。 色々試行錯誤してうまく言った事だけ書いているんですが、TDDの扱いやペアプロについてなど 結局チームになじまなかったものもあり、ここにあげた方法も万人に効果がある事ではないかもしれません。 でも、こういう事でも自分用の備忘録として*2残しておきます。

*1:ステートメントカバレッジっていうんだっけ?全ての行を網羅すること

*2:プラスちょっとでも誰かの助けになればと