[OutSystems] ユニットテスト in OutSystems

OutSystems でユニットテストって書くべきなの？という議論を支えるための資料を目指しました

Transcript

1. ユニットテスト in OutSystems 2024-12-05 OSUG*OJEC 合同開催 in Osaka 伊藤忠テクノソリューションズ 片野 潤一（@kata_junn） ～あるいはユニットテストで幸せになるための方法論～
2. 片野 潤一 かたのじゅんいち / かたじゅん 伊藤忠テクノソリューションズ（略称：CTC） 主業務 ローコードプラットフォーム： OutSystems の推進 - プリセールス、技術支援 - トレーニング講師、講師育成 @kata_junn kata_junn 社内活動 - 社内 OutSystems Developer 向け勉強会開催、登壇 - Webinar 企画、登壇 社外活動 - OutSystems User Group、Qiita、名城大学非常勤講師 OutSystems 経験 - 約 9 年、OutSystems 資格全て
3. 本日のセッションの目的 ※ 後半の実装方法は O11 ベースにお話しします、ODC ではその限りではありません OutSystems 開発において、ユニットテストの効果を得られる 無理のない方法論を布教すること ユニットテストを書いていない方に、書いてみようかな …という気持ちになっていただくこと “ユニットテスト”というものとその効果を理解して頂くこと
4. ユニットテスト is 何？ 分岐網羅、境界値、同値分割、ペアワイズ、状態遷移、等々… テスト対象 テストドライバ ①呼び出す ②処理結果の 正しさを検証する （OutSystems だと） Action 本来の処理の代わりにテスト 対象を呼び出すための実装 ※プログラムで書いて自動化しておく
5. ユニットテストは何をもたらすのか？ エラー検出時期と対応費用の関係を表したグラフはどれか, 小倉 美香, 2010-02-24, 日経XTECH, https://xtech.nikkei.com/it/article/COLUMN/20100120/343445/
6. ユニットテストは何をもたらすのか？ • ソフトウェア品質特性の一つである、変更容易性を向上させ ることができる 変更容易性：必要な変更をストレスなく行えること • プロジェクトの停滞を回避し、適切な開発スピードを長い間 維持できるようになる • プロジェクト開始直後は生産性が高かったけれど、時間が経つ につれて低くなってない？…が避けられる手段になり得る 開発プロジェクトの成長を持続可能な状態に保つ テストの自動化によってセーフティクリティカルなソフトウェアのテス トをシフトレフトする, htakahashi, 2017-10-05, https://parasoft.techmatrix.jp/%E3%83%86%E3%82%B9%E3%83%88% E3%81%AE%E8%87%AA%E5%8B%95%E5%8C%96%E3%81%AB%E3%8 2%88%E3%81%A3%E3%81%A6%E3%82%BB%E3%83%BC%E3%83%95 %E3%83%86%E3%82%A3%E3%82%AF%E3%83%AA%E3%83%86%E3% 82%A3%E3%82%AB%E3%83%AB • プロダクションコードに変更を加えても、退行が発生しない ことに自信が持てるようになる。生産性にも寄与する。 開発者体験の向上
7. 世の風潮的には、ユニットテストは有用かつ当たり前 “単体テストを導入することは当然のことと思われるようになってきました Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス（初版 第3刷）, 2021-11-29, オライリージャパン, 12章 ユニットテスト “バグの防止に続くテストの最重要目的は、エンジニアの生産性の改善である - 規模が小さく、高速で決定的 - 開発者が頻繁に実行でき、フィードバックを直ちに得られる - テスト失敗時に何が間違っていたのかを理解しやすい ―――単体テストに関する議論は 「単体テストを書くべきか？」から「良い単体テストを書くとはどういう意味 なのか？」に移ってきており ――― 単体テストの考え方/使い方（初版 第7刷）, 2022-12-28, マイナビ出版, 第1章 なぜ、単体（Unit）テストを行うのか
8. 7 OutSystems プロジェクトで ユニットテスト書いてるところ 少なくない？
9. 8 わかった！ ローコード開発には必要ないか ら書いてない、とか？
10. OutSystems プロジェクトにユニットテストは書くべき？ 書くことを強く推奨します OutSystems の実装はスクラッチ開発を抽象化し省 力化しているだけに過ぎない つまり本質的にはプログラミングであり、要件に変 更が入れば実装に変更が入る 変更の正しさは動作しなければ確認ができず、手動 テストではフィードバックが遅い 特に OutSystems のフローは全貌は理解しやすい反 面細かなプロパティは見通しが良くなく、デグレー ドのリスクはスクラッチ開発と同様に存在する こういうのをバグなしで直せるかっていう話
11. 10 じゃあなんで みんな書いてないの…？
12. ユニットテストと呼ばれるものが持つ性質 • 1単位の振る舞いを検証すること • 実行時間が短いこと • 他のテストケースから分離された状態で実行されること “自動化されていて、次の3つの性質を全て備えるもの 単体テストの考え方/使い方（初版 第7刷）, 2022-12-28, マイナビ出版, 第2章 単体テストとは何か？
13. ユニットテストと呼ばれるものが持つ性質 • 1単位の振る舞いを検証すること • 実行時間が短いこと • 他のテストケースから分離された状態で実行されること “自動化されていて、次の3つの性質を全て備えるもの 単体テストの考え方/使い方（初版 第7刷）, 2022-12-28, マイナビ出版, 第2章 単体テストとは何か？ - テストケース同士が影響を及ぼさないこと - つまり、共有依存を排除しなければならない - OutSystems において、共有依存の代表的なものはデータベース - OutSystems でユニットテストが書かれない最大の要因と考える
14. OutSystems のユニットテストで負の感情を覚えるポイント 共依存（主にデータベース）を排除しづらい データベースは全ての開発者＋動作しているアプリケーションで共通 これを考慮するとテストを書くのに非常に大きなコストがかかる フィードバックを得られるまでの手順が長い（＝スローテスト） ※回避不可・軽減可 テスト対象を Publish ＋テストコードの参照を更新して Publish する必要がある というか本当だったらローカルで実行したいんよ カバレッジ率が取れない ※回避不可 デッドコードがわからない Public な Action しかテストができない 非 Private な Action はテストができない
15. OutSystems でユニットテストを書く2大巨頭 テスト系で唯一の Supported 黒魔術でユニットテスト ”らしさ” を実現 BDDFramework Testing Framework - OutSystems の仕組みに則ってテストの 仕組みを提供 - Client Action をテストする兄弟 Forge もある - Mocking 機能で共依存を排除可能 - Private な Action もテスト可能 - デフォルトでテスト終了時にロールバック - O11 のコード生成の仕組みが変わると動かなくなる https://www.outsystems.com/forge/component- overview/12754/testing-framework-o11 https://www.outsystems.com/forge/component- overview/1201/bddframework-o11
16. 2つの Forge まとめ（コスト観点） テスト対象のAction Public Client Server Action の 呼び出しがない 〇 やりやすい － 非対応 Server Action の 呼び出しがある △ Server 側のセットアップ/後 始末にコストがかかる － 非Public Client ー － 非対応 － 非対応 Public Server 共有依存がない 〇 テスト可、やりやすい 〇 やりやすい 共有依存がある × 共有依存のセットアップ/後始 末にコストがかかる。動いて いるアプリとも競合する。 〇 Mock 機能があるためやりやすい 非Public Server 共有依存がない × テスト不可 運用で、_ や private 等を Prefix としてつけ、Public に する方法もあるにはあるが、 アンチパターン 〇 テスト可 共有依存がある × 〇 Mock 機能があるためやりやすい BDDFramework Testing Framework ※ Screen Action など、何を使ってもテストができないものもあります。そういうのは E2E で頑張りましょう！
17. 単体テストの考え方/使い方（初版 第7刷）, 2022-12-28, マイナビ出版, 第1章 なぜ単体テストを行うのか？ コードベースの 特に重要な部分のみが テスト対象となっていること 優れた（＝コスパの良い）テストが持つ特徴
18. 2つの Forge まとめ（コスト観点） テスト対象のAction Public Client Server Action の 呼び出しがない 〇 やりやすい － 非対応 Server Action の 呼び出しがある △ Server 側のセットアップ/後 始末にコストがかかる － 非Public Client ー － 非対応 － 非対応 Public Server 共有依存がない 〇 テスト可、やりやすい 〇 やりやすい 共有依存がある × 共有依存のセットアップ/後始 末にコストがかかる。動いて いるアプリとも競合する。 〇 Mock 機能があるためやりやすい 非Public Server 共有依存がない × テスト不可 運用で、_ や private 等を Prefix としてつけ、Public に する方法もあるにはあるが、 アンチパターン 〇 テスト可 共有依存がある × 〇 Mock 機能があるためやりやすい BDDFramework Testing Framework ※ Screen Action など、何を使ってもテストができないものもあります。そういうのは E2E で頑張りましょう！
19. テスト対象のAction Public Client Server Action の 呼び出しがない 〇 やりやすい － 非対応 Server Action の 呼び出しがある × Server 側のセットアップ/後 始末にコストがかかる － 非Public Client ー － 非対応 － 非対応 Public Server 共有依存がない 〇 テスト可、やりやすい 〇 やりやすい 共有依存がある × 共有依存のセットアップ/後始 末にコストがかかる。動いて いるアプリとも競合する。 〇 Mock 機能があるためやりやすい 非Public Server 共有依存がない × テスト不可 運用で、_ や private 等を Prefix としてつけ、Public に する方法もあるにはあるが、 アンチパターン 〇 テスト可 共有依存がある × 〇 Mock 機能があるためやりやすい BDDFramework Testing Framework ※ Screen Action など、何を使ってもテストができないものもあります。そういうのは E2E で頑張りましょう！ ここが OutSystems でユニットテストをすべき箇所 ユーティリティ ユーティリティ、重要なビジネスロジック
20. まとめ ユニットテストは何をもたらしてくれるのか？ 変更容易性を高めることにより、ソフトウェア開発の生産性・開発者体験を維持できる システムが大きくなっても生産性を落とさない、ということを実現できる OutSystems においてもユニットテストの利益は享受できるのか？ やりづらいポイントはあるが、享受（＝テストを書くコストをペイ）することはできる やりづらさは、Testing Framework を使用することでクリアできるものがある 何に対してテストを書いたらいい？ 価値の高いコードに絞るのが良い OutSystems だと価値の高いコードは、Public Client Action と Server Action に集中する それぞれ、BDDFramework Client Side と Testing Framework を使えば書くことができる
21. オマケ ODC でも同じことが言える？ O11 と Public の意味合いが変わったため、同じことが言えない 生成されるコードも変わった（はず）ので、Testing Framework も対応できていない え、じゃあどうしたら…？ 製品ネイティブな機能としてユニットテストをサポートするよう、 ODC エンハンスリクエストを挙げましょう！！！！！！！！！！！！！！！ ユニットテスト以外はどうなの？ 現状は O11 も ODC もフロントエンド部分は大きく変わらないため、 E2E テストは O11 から ODC に移行しても（ほぼ）そのまま動きます
22. 参考：その他の負のポイントへの対処 フィードバックを得られるまでの手順が長い（＝スローテスト） OutSystems の製品仕様的にどうしようもない Publish したら自動的にテストを走らせ、可能な限り素早く知らせる方法を採用するのが関の山 参考：OutSystemsでPublishしたら自動テストを走らせる https://qiita.com/jyunji_watanabe/items/b1b79281a15b8cadc713 ※ Publish が頻発すると大量に走ってしまうことを避けるために、キューイングされる数を最 大1にする、などの工夫をすれば効率的になると思われる（未検証）
23. 参考：その他の負のポイントへの対処 カバレッジ率が取れない OutSystems の製品仕様的にどうしようもない カバレッジ率の高さと優れたユニットテストであることの相関関係は必ずしもないが、 デッドコード（到達不能コード）を機械的に検出できないのは非効率 残念ながらコードレビュー/テストコードレビュー以外の方法はない
24. https://speakerdeck.com/kata_junn/outsystems-o11- yuzanizeng-ru-odc-yi-xing-nibei-eteokutoliang- sasounakoto ODC 移行前に E2E 書いておくと 良さそう、という話 参考というか宣伝というか Testing Framework の紹介 https://speakerdeck.com/kata_junn/outsystems-testing- framework-gaii-totemoii