Newer
Older
TIASshot / docs / 01_GUIDE / GUIDE_08_テスト方針.md

テスト方針 (Testing Policy)

本プロジェクトのテストの種類・粒度・対象範囲・実行タイミングを定める. 具体的な回帰テスト手順は TEST_01_テスト仕様 を参照する(本書は方針,TEST_01 は具体手順という役割分担).

基本方針 (Basic Policy)

本プロジェクトは実機カメラ(Lucam / ImagingSource)・光源・ネイティブライブラリ(OpenCvSharp)に強く依存する一方で,画像処理・色補正・設定読み込み等のハードウェアに依存しない純粋ロジックも含む.この性質に合わせ,コードを 2 層に分けてテストする.

  • ピュアロジック層: ハードウェア・UI・スレッドに依存しない計算/変換ロジック.自動テスト(単体テスト)で回帰を担保する
  • ハードウェア結合層: カメラ SDK・Form1(WinForms UI)・撮影/プレビューのスレッド・コールバックに密結合した処理.自動テストの対象外とし,ビルドテスト+手動テスト+実機回帰テストで担保する.

「テストできない」と「テストしていない」を混同しない.ハードウェア結合層は原理的に自動テストが困難なため対象外とするが,ピュアロジック層は自動テスト可能であり,必ずテストを書く.

標準に則る.NUnit の慣例(AAA: Arrange-Act-Assert)に従い,テストは実装のなぞり書きではなく仕様(期待される入出力)を基準に書く.

テストの種類 (Test Types)

種類対象自動化実行タイミング
単体テストピュアロジック層自動(NUnit)コミット前・/implement Phase 2
ビルドテストソリューション全体自動(MSBuild)全コミット前
回帰テスト色補正・チャート検出の出力半自動(基準データ比較)リファクタ・修正の前後
手動テスト起動〜撮影〜保存の一連動作手動(実機)機能追加・修正の完了時

回帰テスト・手動テストの具体手順は TEST_01_テスト仕様 に記載する.

テスト対象の切り分け (Test Scope)

どのクラス・処理を自動テストの対象とするかを明示する.新しいコードを追加した際は,この表に従って対象/対象外を判断する.

自動テスト対象(ピュアロジック層)

対象テスト内容の例
ColorCorrection/ColorCorrector次元拡張(ExtendMat)・変換行列算出・色変換の入出力.既知の入力 Mat に対する出力 Mat/数値の検証
ChartDetection/ChartDetector既知のチャート画像を入力したときのマスク位置・検出結果の幾何的検証
Config設定 XML のパース・型変換・範囲フィルタ(例: チャネル数の 4〜17 絞り込み)
Utils/IoUtilCSV の読み書き往復(SaveMatToCsvLoadMatFromCsv)で値が保たれること
ゲイン更新比率の計算(GetRatio 相当)入力値・目標値・更新レートに対する比率計算

自動テスト対象外(ハードウェア結合層)

対象対象外の理由
Cameras/CameraBaseIScamLucam のカメラ制御・撮影/プレビューカメラ SDK(dll.* / TIS.Imaging.*)・フレームコールバック・実機に依存
撮影/保存のスレッド連携(RunShotLoop / SaveThreadカメラフレーム取得・Form1 に依存.スレッド安全性は設計レビューと実機で担保
UI/Form1UI/PreviewMonitorWinForms UI スレッド・画面描画に依存
LightSource光源のシリアル通信(実機)に依存

※ ハードウェア結合層に手を入れた場合は,自動テストの代わりに設計レビュー+実機回帰で挙動を確認する./implement の Tester フェーズでは,対象がハードウェア結合層の場合,無理にモックを作らず設計レビューで判断してよい.

フレームワークと配置 (Framework & Layout)

  • フレームワーク: NUnit(NUnit3TestAdapter で Visual Studio / dotnet test から実行).
  • テストプロジェクト: TIASshot.Testsx64 / .NET Framework 4.8.本体と同一ターゲット).
  • ネイティブ依存: ColorCorrector 等のテストは OpenCvSharp のネイティブ DLL をロードするため,テストプロジェクトも x64 必須かつ OpenCvSharp ランタイムを参照すること(プラットフォームを AnyCPU にすると Mat 演算が実行時に失敗する).
  • 配置: ソリューションルート直下にテストプロジェクトを置く.
TIASshot/                  ← ソリューションルート
├── TIASshot.sln
├── TIASshot/             ← 本体プロジェクト
└── TIASshot.Tests/       ← テストプロジェクト(NUnit)
    ├── ColorCorrectorTests.cs
    ├── ConfigTests.cs
    └── ...
  • 命名: テストクラスは <対象クラス>Tests,テストメソッドは「対象_条件_期待結果」が分かる名前にする(日本語名も可).
  • 粒度: 1 テストにつき 1 つの検証観点とする.1 メソッドで多数の Assert を詰め込まない.
  • テストデータ: 入力画像・基準 CSV 等は TIASshot.Tests 配下の専用フォルダ(例: TestData/)に置き,テストから相対参照する.

テストの実行 (Running Tests)

テストプロジェクトは本体に合わせたレガシー形式(packages.config)のため dotnet test は使えない.ビルド後に vstest.console.exex64 で実行する(ネイティブ DLL を x64 でロードするため).

& "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\MSBuild.exe" TIASshot.sln /t:Build /p:Configuration=Debug /p:Platform=x64
& "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" "TIASshot.Tests\bin\x64\Debug\TIASshot.Tests.dll" /Platform:x64

Visual Studio 上ではテストエクスプローラーから実行できる(プラットフォームを x64 にすること).

モック方針 (Mocking)

  • 過剰なモックを避ける.ピュアロジックは実値(実際の Mat・数値)で検証する.
  • 静的依存の扱い: Config のような静的クラスへの依存がテストの妨げになる場合,テスト容易化のための最小限のシーム(引数化・依存の注入)を導入してよい.ただし本番の挙動は変えないこと.
  • ハードウェア SDK はモックしない.モックしてまでテストする価値が低く,対象外(ハードウェア結合層)とする方針と整合させる.

カバレッジ方針 (Coverage)

  • 数値的なカバレッジノルマは課さない.カバレッジ率の達成自体を目的化しない.
  • 代わりに,重要な計算経路を網羅することを定性的な目標とする.具体的には,色変換行列の算出・次元拡張・CSV 往復・ゲイン更新比率といった「誤ると出力が壊れる中核ロジック」にテストを行き渡らせる.

既存ドキュメントとの関係 (Relation to Existing Docs)

  • 本書(GUIDE_08)はテストの方針を定める.
  • TEST_01_テスト仕様回帰テスト・手動テストの具体手順(基準データの作成・比較方法・合格条件)を定める.
  • 自動テスト(単体テスト)の具体的なケースが増えた場合は,docs/06_TEST/ に追記する(本書には方針のみ残し,個別ケースは重複させない).