Month: December 2023

本ブログではSAP Cloud Application Programming Model（SAP CAP）におけるテストの考え方と、単体テストおよび内部結合テストのテストコードの書き方についてご紹介します。CAP on JavaとCAP on Node.jsでテストの書き方が異なりますが、本ブログではCAP on Node.jsでのテストについて触れてまいります。本ブログの内容はトライアル環境でも実施可能なので、ぜひお読みいただきながら手を動かしていただき、実際にテストコードを作成してみてください。 本ブログはSAP CAPフレームワークを利用してアプリケーションを開発されたことのある方向けの内容となっております。SAP CAPフレームワークについてご存知ない方はこちらのSAP CAP公式ドキュメントを、SAP CAPフレームワークを利用したアプリ開発をハンズオンで試してみたい方はこちらのチュートリアルをご参照ください。 SAP CAPにおけるテスト自動化の考え方 サンプルアプリケーションの作成  テストの書き方 単体テスト 内部結合テスト テストの実行 おわりに みなさんはCAPアプリケーションに限らず、クラウドアプリケーションでテストコードを書かれたことはあるでしょうか？テストコードは開発した成果物の挙動を保証するための非常に重要なものですが、機能の実装よりも後回しになり、開発の遅れ等に伴って結局テストコードにまで手が回らずに終わってしまい、単体テストをスキップして検証環境にデプロイしたアプリケーションの画面を実際に動かして手動でテストを行うケースも多いかと思います。 「コストも時間もかかる手動テストだけでアプリケーションを保証し切る」のは、一度作ったアプリケーションは塩漬けしてほとんど手を加えることがない従来の完全なウォーターフォール型の開発ではまだ理にかなっているかもしれません。しかし、クラウドアプリケーションではそうはいきません。ランタイムやライブラリのバージョンアップやセキュリティパッチ適用などで、大なり小なりアプリケーションを継続的に修正することが求められます。言わばアプリケーションの新陳代謝が必要と言えますが、そのたびにテストを手動で実行するのは現実的ではありません。 このセクションではみなさんにテストの自動化についてモチベーションを持っていただくために、さらに考え方やメリットについて触れていきます。 1-1. 自動化のスコープ 一言にテストといってもいろいろあります。ウォーターフォール型の開発では単体テストや結合テスト、システムテスト、受け入れテストを通じて開発工程の各ステップを検証していきます。これらのテストを全て自動化するのかというと、答えはNoです。 自動化したテストは「いつでも、どこでも、誰でも」実行できることが好ましいです。自動化したテストは開発者がコマンドで実行するほか、ビルド時に実行させたり、それをCI/CDパイプラインの中で自動的に実行させることができます。仮に外部結合テストやシステムテストを自動化させた場合、テスト実行時に外部システムとのデータ連携も実行されてしまいます。この場合、テストを実行する環境から外部システムへアクセスできなかったり、外部システムが停止しているとそもそもテストを実行できません。また扱うデータが本番相当のものだとそのデータをテストにより改変してしまう可能性もあります。これらは「いつでも、どこでも、誰でも」のポリシーに矛盾してしまいます。 また、自動テストはソースコードに記述したロジックの正しさを検証、保証して次のステップへ確実に繋げていくものになります。このことから、自動化すべきテストは単体テストと内部結合テストであると考えることができます。 また、すべてのクラスやメソッドを漏れなく自動テストで守り切るべきかというと、それもNoです。必要な部分、効果の大きい部分に絞って効率的にテストコードを書くべきです。例えば、クリーンアーキテクチャに従って適切に責務を分離してソースコードを記述した場合、DBや外部システムへの接続処理はGateway（Repogitory）層のクラスに、APIを公開する部分はController層のクラスに分離できます。適切に分離できていればこれらのクラスにはビジネスロジックは記述されていないはずです。単体テストではロジックの正しさを保証するためのものなので、Gateway層やController層のテストを省くことができます。 クリーンアーキテクチャ[引用元：The […]