単体試験のコードは、本番コードより難しいぞ！という話

どうも、本職エンジニアです。最近仕事で久しぶりに開発工程をやっているので、この工程回りの話をしていきたいと思います。

まず開発工程はざっくり「製造」「単体試験」に区分されることが多いです。また、結合試験以降の工程は「試験工程」とまとめられることが多いですね。ということで今回は製造及び単体試験についてのお話がメインとなります。

製造はそこまで躓くことはない。はず！

まず製造工程から話していきます。規模感にもよりますが、一般的なプロジェクトはプロジェクト規定みたいなものを作るチームがあり、ある程度コードのひな型を用意してくれたりします。（筆者もこういうチームだったり）

なので、コーディングの難易度という視点ではそこまで難しくならないことが多いです。ネックになるのはクライアント側のコーディングだと思っていますが、これも慣れてしまえばそこまで苦になることはないでしょう。最近はAIも利用できたりするので、習得までのスピード感はいままでよりは早くなりますしね。

バックエンドに関しては経験者が集まりがちです。何だかんだ日本だとJavaが多い気がしますね。だいたいのPJでは技術要件としてバックエンド側の言語を指定しているので、スキルの差はあれど経験者が集まりやすくなっているはずです。なので、コーディング周りの規定を作る際はバックエンド側の記述はやや緩めで良かったりするという側面があります。どうせみんなできるのでね。PJ固有のフレームワークなんかがあればそれらを重点的に説明していくイメージです。

逆にプロジェクトとして「みんな慣れてないだろう」と思われる言語を採用する場合は、言語仕様を含めて説明をしていくことになります。クライアント側は利用言語がプロジェクトによってまちまちになりがちなので、ちょっと濃い目に規定が作られたりしますね。

という訳で、言語に慣れていてもそうでなくても、ある程度みんながコーディングできるように工夫がされているので、製造で躓くことはあまりないだろうと思っています。

単体試験はむずい

さてここからが本題です。はい、単体試験はとても難しいです。
ざっくり理由を箇条書きで上げていきましょう。

• 製造と比べPJルールが厳密に規定されないことが多い
• Junitなど、テスト用フレームワークの理解が必要
• もちろんテスト対象のコード理解も必要

とまあこんな感じになります。
ではひとつずつ解説していきましょう。

プロジェクトルールが規定されないがち

単体試験の工程はやることが結構あります。
例えば

• 単体チェックリスト作成
• 単体試験
• B票の記載
• 静的解析ツール実行
• コード規模取得
• カバレッジ取得
• その他エビデンス取得
• 品質評価

と思いつくことをざっと挙げてもこのくらいはやることがあります。
特に今回ネックになるのは品質評価にかかわる部分です。

単体試験工程の策定においては、品質評価周りのルールを優先的に定めていくことになるため、技術的な部分への準備がどうにも追い付かなくなりがちです。しかも、だいたいの場合製造と単体試験は同時に走っていくことになるので、準備期間では製造ルールもやっていたりしますしね。こんな感じなので、単体試験のコードルールはおざなりになりがちです。

人によって検証方法がバラついたり、場合によっては正しい検証が行われなかったりするリスクがあります。これを防ぐために、少なくともチーム毎に検証内容、検証方法は定めておく必要があるでしょう。これなしで進んでしまうと結合試験とかでしょうもないバグが発生してしまいますからね。。もちろんプロジェクトとして規定できるのであれば、その方が良いです！

テスト用フレームワークの理解が必要

テスト用フレームワークはどの言語にもだいたい用意されており、言語ごとにデファクトスタンダードが存在するので、経験者には問題なく扱えることが多いですが、試験工程は比較的若いメンバで実施することになりがちです。こういった場合、難易度はテストコード ＞ 本番コードになってしまうんですよね。

なので、慣れていない人が初めて単体テストの実施を行うと「何をどうやって検証すればいいんや！？」となってしまう訳です。まあこの辺りは自分のチームの先輩とかに聞いてやってもらえればいいのですが、その先輩もあんまり。。みたいなことがチームによっては発生してしまいます。

単体試験工程は「スキルレベルが進捗に大きく影響する」工程でもある訳ですね。筆者の経験則としても、いちばん進捗遅延が発生しやすい工程であると思っています。

もちろんテスト対象のコード理解も必要

もちろんテスト対象のコードを理解していないと、単体試験のコードを書くのは難しくなってきます。このモジュールを正しく動作させるには、このモジュールをDIしなければならない、検証のためにこのプロパティファイルが試験環境にも必要である。。など、試験の前提となる状態を作り出すためにはテスト対象のモジュールを理解しなければなりません。

だいたい1度やってしまえばあとはだいたい同じ感じで作れると思いますが、このモジュールとこのモジュールは構成が近い、などの観点で作業ができないと効率が悪くなります。コードを理解することで、そのコードに合わせた正しいテンプレートを利用できる、みたいなイメージですね。

単体試験を軽視してはならない

なぜか新人は不慣れな人がアサインされやすい工程ですが、たぶんあんまり良くないです。製造の方がまだいいです。もしくは画面を叩いて画像をキャプチャするタイプの試験から始めるべきです。

もちろん指導できる先輩がしっかりいて、その人の下で単体試験コードを書くのであれば得られるものは大いになるでしょう。しかしそうでないのであれば、そこそこのストレスになりがちだと思います。マトリックスタイプのテスト仕様書を読むのにも慣れてないでしょうしね。

単体試験工程で発見できなかったコードのバグは後工程で見つからずに本番に行ってしまうケースも多々あるため、この工程を軽視してしまうとかなり品質に多くの影響を与えます。しかも単体試験工程で発生しうるバグに関しては基本的には自責です。結合試験や運用試験レベルのものは要件定義不備などに落とせるケースはありますが、単体試験レベルのバグは勝ち目なしです。

なので、筆者は単体試験工程はレベルの高いエンジニアを揃えて実施するべきだと思っています。

最後に

単体試験がうんぬんと言ってきましたが、簡単な工程なんか無いです。稼働が安定しがちなのはここ、みたいのはあるかもですけどね。個人的には基本設計工程が一番稼働が安定するような気がしています。やっていることは難しいんですけどね。

単体テストの考え方/使い方 / 原タイトル:Unit Testing Principles Practices and Patterns[本/雑誌] (Compass) / VladimirKhorikov/著 須田智之/訳

ショップ: ネオウィング 楽天市場店

¥4,488

※価格やショップ情報は楽天のものです

楽天で見る Amazonで探す