# 回帰テスト ## 回帰テストの導入 ソフトウェア開発の動的な世界では、アップデートや機能強化を通じてアプリケーションの信頼性と機能性を確保することが重要です。ここで登場するのが回帰テストです。これは一般的なソフトウェア開発では広く認識されている概念ですが、Claris FileMakerコミュニティにおいては比較的新しいものです。回帰テストは、最近のスクリプトやスキーマの変更が既存の機能に影響を与えていないか、または破損していないかを体系的に確認し、新しいバージョンをクライアントに提供した後でもアプリケーションが期待通りに動作し続けることを保証するプロセスです。 ## なぜ回帰テストが重要なのか * **整合性の維持**: FileMakerプロジェクトが進化する中で、回帰テストは既存の機能の整合性を維持し、新しい変更によってエラーが導入されないようにします。 * **品質向上**: 回帰テストは、アプリケーションの全体的な品質を向上させ、より安定した信頼性の高いソフトウェア製品の開発に貢献します。 * **自信向上**: 変更が既存の機能を壊さないことが確認できるため、開発者や関係者はアプリケーションの継続的な改善に対して自信を持つことができます。 ## テスト手法 回帰テストでは、個々のコンポーネント（「ユニット」）と、それらの外部依存関係（「インテグレーション」）との相互作用の両方を検証します。これにより、ブランチに変更をリリースする前や、環境間での更新を展開する前に、アプリケーションの堅牢性を確保します。 ### ユニットテスト これらのテストは、アプリケーション内の個々のコンポーネントや関数に焦点を当て、それぞれを分離してその正確性を確認します。例えば、請求書内の合計金額を計算するスクリプトをテストする場合が考えられます。予め定義された入力をこの関数に与え、出力が期待通りであるかを確認するテストスクリプトを書くことで、アプリケーションの最小単位でも正しく動作することを確保できます。 ## インテグレーションテスト ユニットテストが個々の部品を調べるのに対し、インテグレーションテストはそれらの部品がどのように連携するかを確認します。例えば、行アイテムを追加して最終的な請求書を生成するまでの請求書作成プロセス全体をテストすることが考えられます。別の例として、特定のJSONペイロードを用いてAPIから期待されるHTTPコードを受け取ることを検証することもあります。これにより、個々のコンポーネントが連携して正しく機能し、エンドツーエンドのプロセスがエラーなく動作することが確認できます。 ## Devinを使用した回帰テストの実装 Devinは、FileMakerのスクリプトワークスペースとシームレスに統合されるシンプルなテストフレームワークを提供し、テストスクリプトの作成を可能にします。 * **整理されたテストスクリプト**: ファイルのスクリプトワークスペース内にテスト用のフォルダを作成します。デフォルトでは、Devinは「Tests」フォルダを探しますが、カスタム名を指定することもできます。Devinは、このフォルダおよびそのサブフォルダ内のすべてのスクリプトをテストスクリプトとして解釈します。 * **成功の定義**: テストスクリプト内で `Exit Script [True]` コマンドを使用して成功を示します。テストスクリプトが`True`を返さない場合、Devinはそのテストを「`FAILED`」と解釈します。

「3つのテストスクリプトを含むスクリプトワークスペースの例」

次に、Devinのプロジェクトワークスペースでモジュール -> テストタブにアクセスして、[「テストスクリプトを読み込む」](https://docs.devin.fm/jp/gaido/projects/tests/load-test-scripts)と[「テストスクリプトを実行する」](https://docs.devin.fm/jp/gaido/projects/tests/run-test-scripts)を行います。

「dev」ブランチのモジュールでテストが実行されている例

{% hint style="warning" %} Devinは、テストを実行するためにFileMaker OData APIを利用します。テストを正常に実行するためには、モジュールをDevinに追加する際に指定されたアカウントに対して、odata拡張権限が有効になっていることを確認してください。さらに、FM OData APIでは、スクリプト名が数字で始まることや特殊文字を含むことが制限されていることに注意してください。 {% endhint %}