【Outsystems】BDDFrameworkを使用したテストの概要

# はじめに
OutsystemsではBDDFrameworkと呼ばれるテスト用のモジュールが公開されている。

テストを行う際はこのBDDモジュールとテスト対象となるモジュールを読み込んだテスト用のアプリケーションを作成する必要がある。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/98e79001-1f9b-f97b-cf2a-434161ebeb72.png)

ローコードのロジックとテスト対象からインポートしたロジックを組み合わせてテストロジックを作成し結果の整合性を検証してテストを行う。

以下のチュートリアルを実施してみたのでポイントをまとめる
参考：[OutSystemsローコードプラットフォームでのBDDテストの完全ガイド](https://www.outsystems.com/blog/posts/bdd-testing/?_gl=1*112wwch*_ga*MjAwNzI3OTI3Ny4xNjgzNjAxNTE3*_ga_ZD4DTMHWR2*MTY4NjYzMzY2Ny4yOS4xLjE2ODY2MzM2OTQuMzMuMC4w)

# BDDアプリケーションの作成
BDDをForgeからインストールする
Forge：[BDDFramework](https://www.outsystems.com/forge/component-overview/1201/bddframework)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/ed9545ed-8ac7-4e3b-49a8-59ee2f32d364.png)

New ApplicationからBDD Frameworkを選択しアプリケーションを作成する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/af8cb0af-b329-73f6-3574-fc88fdc9bc0c.png)

作成したアプリケーションの中では、BDD Frameworkのモジュールタイプが選択できる
このモジュールに組み込まれたテストロジックや検証結果のScreenを使用してテストを実装していく。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/88aa53c5-59ab-b54f-d8df-3fdf9b45739d.png)

今回のチュートリアルでは既に公開されているECサイトアプリを読み込みテストを実装している
テスト対象のモジュール：[eCommerce](https://www.outsystems.com/forge/Component_Overview.aspx?ProjectId=573)

BDDアプリケーションに対象のモジュールを読み込む際、ロジックやエンティティの公開範囲がPublicになっていないとインポートできないため注意
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/a1575388-eb9b-e496-ba54-2f2615fddc27.png)

最終的にBDDモジュールとテスト対象を含む構成のテスト用アプリケーションが作成されれば準備が完了
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/6bb0e3c7-a5ab-b629-acab-a16fe7baf6fe.png)

# BDDが準備してくれるUI、ロジック

BDDの機能は
- 検証結果を表示するためのUI、画面(Screen)
- 検証を実行するための組み込みロジック

に大別できると感じた。
既存のテストと違いコンソールを使用せず検証結果を画面で確認する

以下はチュートリアルのテスト作成後の確認画面
どこかでエラーや例外が発生すれば設定した詳細情報と共に画面に表示される
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/ad96ee30-1802-3f64-7fa2-cc01c7b9f05f.png)

またBDDモジュールに準備されたロジックで予期されれる結果と実際の結果の整合性を検証し画面に出力する
以下はAssertロジックなど
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/4d1c080d-cb72-6197-7796-3e18b6d20d35.png)

# テストケースを作成する
テストケースは
1. GIVEN：前提条件
2. WHEN：ユーザー操作などのトリガー
3. THEN：期待される結果に
4. AND：補足して確認する事
に段階分けして定義する([Gherkin言語](https://www.guru99.com/gherkin-test-cucumber.html)と呼ばれているらしい)

例として、
GIVEN：登録データの「顧客名」と「住所」に同じデータがすでに登録されている
WHEN：ユーザーが登録ボタンを押下する
THEN：エラーメッセージ「既に登録済みのデータです。」が表示されることを確認する
AND：データベースにデータが登録されていないことを確認する

参考：[OutSystemsでテスト自動化ツール（BDD Framework）を利用してみた](https://www.tdi.co.jp/miso/outsystems-bdd-framework)

実際テスト用のブロックを使用してスクリーンを作成すると上記の段階ごとにロジックを紐づけるUIが作成される
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/5df2e6b2-b2c6-090e-8c1d-172b35cc2405.png)

ロジックによる検証結果はこれらの画面に紐づき出力される

下記はGivenの段階の「指定した名前の商品がエンティティに存在する」という前提段階を検証するロジックと、結果を出力するためのAsertメソッド
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/c1f44cc6-af91-85e2-6250-abe4f4e04414.png)

これを各段階に沿って行う事で１つのシナリオについてのテストを作成する

途中で検証結果に例外が発生した時はこのようにRedが出力され、その後の処理はスキップされる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/601137/03865065-6d24-b725-bc8f-a35bb55ba909.png)

# 疑問に感じた点
- 実際のモジュールを使用してテストするためエンティティ操作も本当に実行される
チュートリアルではリールバックのロジックを作成しテスト後に実行していたが、結果としてテストによるDB操作、ロールバックによるDB操作が発生しており、テスト対象のクローンを用意しないとエンティティを壊してしまう恐れがあると感じた。

# まとめ
今回はテストを実行するためのツールとしてBDDFrameworkを触りだけ調査した。

BDDFrameworkには、出力を検証するためのロジックと結果を表示するUIが準備されており、テストを作成する際は特定のシナリオをGIVEN、WHEN、THEN、ANDの段階に落とし込み、対応するシナリオを実現するロジックと、検証ロジックを組み合わせる事によって可能になる。

今回調査したBDDFrameworkが実行するテストは、特定のシナリオを実現する複数のロジックを検証する複合テストの内容であったが、使い方によってはロジック単体をテストする事も可能であると感じた。
参考：[単体テストおよびAPIテストの自動化](https://success.outsystems.com/ja-jp/documentation/how-to_guides/devops/how_to_automate_unit_testing_and_api_testing/)

また、これらテストを効果的に実行するためにはシステムをどのような構成でモジュールに分化させるかの設計が重要になるとのことである。
参考：[テストを容易にするための開発](https://success.outsystems.com/documentation/11/developing_an_application/testing_your_application/develop_for_testability/)