単体テストの定義が実はバラバラであるということに、気づいたので自分なりにまとめておきます。

個人的な疑問

個人的な体験だと、SIer時代には、単体テストというフェーズでプログラム実装に対するC1網羅試験を設定してテストを実施していました。
UTの仕様書は現場により書いたり書かなかったりでしたが、分岐網羅テストの実施は必要で、
その後詳細設計書のカバレッジを満たすテストを実施していて、それは結合テスト1のような名前で呼ばれていました。
転職後の事業会社では、この単体テストにあたるものがなく、結合テスト１ が 単体テストと呼ばれており特に違和感を感じることはそこまでなかったのですが、
ふと昔単体テストと呼ばれていたテストは何テストだったのだろうと疑問を持ちました。

丁度欲しかった回答があった

この疑問を解決するためにWebを調べていたところ以下の記事を見つけました。
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜若手Webエンジニアのキャリアを考える！

私が、SIer時代に実施していた単体テストは、コードベースの<wbr>単体テスト であり、事業会社で実施している単体テストは 機能ベース単体テスト のように思います。
記事中の以下の言葉が刺さりました。

製品にそれほどの高品質を要求されない場合は、この機能単位の単体テストのみが実施されることが多いです。

機能ベース単体テストと、コードベースの単体テストの併用

品質強化のため、コードベースの単体テストを一部実施したいような場合もあるかと思います。
実施対象の切り分け方法として以下が思い浮かびました。

  • 画面の共通部品をコードベースの単体テストの対象とする

  • 共通ライブラリをコードベースの単体テストの対象とする

  • バグ発生時にビジネスリスクの高い機能はコードベースの単体テストの対象とする

  • 一般的にリスクが高いと考えられる機能はコードベースの単体テストの対象とする
    一般的にリスクが高いコードは、microsoft/ApplicationInspector で可視化できそうに思います。

そして、このコードベーステストの対象としたコードこそXunit系のテスト対象コードの気がします。

コードベースの単体テストを実施はしないが、コードベースの品質を高める

SIer時代は、コードベースの<wbr>単体テスト 時はリファクタリングをしながらテストを実施していました。
これは、コード重複が多いとテストケース数が膨大になるのでテスト前に重複を排除するリファクタリングを実施して、テストケース数を減らすためです。
コードベースの単体テストは自然に開発者にリファクタリングを促す効果もありますが、コストがかかります。

仮にコードベースの単体テストを実施はしないが出来るだけコードベースの品質を上げたい場合は、静的解析ツールを有効に活用するのが良いかと思います。
個人的には、オープンソースの静的解析ツールを使うのであれば、以下を併用します。

  • SonarQube
    ソースコードに対してのチェック、コードクローンの検知を実施してくれる。

  • SpotBug
    コンパイルされたClassファイルに対するチェックで、SonarQubeとはチェック内容が異なります。
    Find Security Bugs というPluginもあり、セキュリティ系のチェックの強化もできます。

参考

コードベース単体テストと、機能ベース単体テスト という言葉でソフトウェア開発現場でのコミュニケーションがスムーズになりそうな気がしますので、積極的に使っていきたいです。
以上です。

コメント

最近の投稿