あなたはどっち派？XSpec系テストフレームワークの構造化流派について / XSpec Title Naming

JaSST nano vol.38(https://jasst-nano.connpass.com/event/322830/) で発表した資料です。
XSpec 系のテストコードで `describe` や `test` や `it` に書く情報や、構造化の仕方って人によって違ったりしませんか？ The Art of Unit Testing, 3rd Edition という書籍にコツが書いてあったので共有します。

Transcript

1. あなたはどっち派？ XSpec系テストフレームワークの構造 化流派について 2024年7⽉16⽇
2. ⾃⼰紹介 名前: bun （今泉⼤樹） 所属: （今⽉転職しました） 認定試験 AWS認定試験12種 JSTQB（ソフトウェアテスト技術者の試験） Advanced Level Test Manager / Test Analyst / Technical Test Analyst 最近の悩み 新しい職場でロボットが出てくるアニメをよく勧 められる（ロボ顔） 本当はスポーツ物も好きだったりする ~ Japan AWS Top Engineer(Services)
3. ユニットテスト/インテグレーションテスト書い てますか？
4. 私はXSpec（XUnit）⾵な記法ができるテスティングフレー ムワークが好きです Jest / Vitest Rspec Cucmber などなど
5. 今回はとある洋書を読んで明確になってきた私なりのテスト コードの書き⽅のTIPSについて話します
6. The Art of Unit Testing Third Edition 作者: Roy Osherove / Vladimir Khorikov Vladimir Khorikov さんは 邦題: 「単体テストの考え⽅/使い⽅」の作者さんです 書籍のコードは JS / TS / Jest でWeb系のエンジニアでもとっつきやすいです
7. 1.テストのタイトルに 含める情報は？ 必要な情報が伝わるタイトルってなんだろう？
8. タイトルに含めたい3つの情報
9. １： テストの対象（SUT）
10. 2： どんな時に（シナリオ or ⼊⼒）
11. 3： 期待する振る舞い
12. 「期待する振る舞い」を検証しようっ て良く聞きますよね 「単体テストの考え⽅ / 使い⽅」でもよくこのように表現される こうすればテスト対象の最終的な振る舞いを変えずにリファクタリングしても、テストは 壊れないとか 逆にテスト対象の振る舞いが変わったらちゃんとテストは失敗して、欲しいフィードバ ックをくれたりとか 例えば「この名前の関数が呼ばれた」などの内部の実装に紐づいていると振る舞いは 変わってないのにテストは失敗する メリットや背景から説明してくれる良書なのでぜひ読んでください
13. さておき‧‧‧命名やタイトルに⼊れたい情報 はOK
14. じゃあどうやって？（どこに？）
15. 2.よく⾒る書き⽅の流 派 ⼤きく分けて2つの流派をよく⾒かける（感想）
16. ： describe や context を使って構造化しよう ぜ派 サンプルコード参考（ほぼ引⽤）: https://www.artofunittesting.com/
17. 2： 極⼒ネストせず平坦にしようぜ派 サンプルコード参考（ほぼ引⽤）: https://www.artofunittesting.com/
18. ちなみに‧‧‧ " テスト対象（SUT ）, シナリオ or ⼊⼒, 期待する振る舞い" という書き⽅は書籍のレビュー中に Tyler Lemke さんから 教えてもらったとのこと 作者も気に⼊られたようで書籍中にこのような⼀⽂が出て来ます カンマ区切りで必要な情報が必要な形式で含まれてて良さそうですよね
19. （感じている）メリット / デメリット メリット デメリット : describe とかで構造化 ⼀⽂が短くなるし、構造化できる こと⾃体がメリット 複数の振る舞いをまとめたり テストが⼤きくなってくると、レビ ューが若⼲しにくくなることも 気をつけないと、何でもかんでもま とめられてしまうなど いけてないネストの深さ 前処理‧後処理を共通化して無 駄に状態を共有 2: できるだけ平坦に派 変更箇所とテストコードのレビュ ー必要箇所がほぼ⼀致 あまりスクロールを要しない 必然的に⼀⽂の⽂章は⻑い 構造化で感じる恩恵を感じられな いこと
20. 書籍の作者さんとしては ⼀部の⼈は describe などで構造化することを嫌うだろうけど、ある種のエレガンスを感じるという（控えめな？）表 現をされている 3つの重要な情報をそれぞれのレベルに分けることができる
21. ちなみに私も基本的には構造化したい そもそも describe とかってそのためにできたのではと思う（未調査） テスト結果を⾒て⾮技術者の⽅でも条件や、その時の振る舞いをパッとわかるようになってたり ただ注意したいこともある describe のネストが深すぎて何をしているかよくわからなくなったり 何でもかんでも「まとめたほうがいいんだ！DRY！DRY」みたいに、 beforeEach などの前処理や後処理にまとめ られ上下へのスクロールを強制されたり 使う時には事前にチームでルールについて合意しておきたい（ふんわりでもいいので） ネストは深くしすぎない（2 か 3 までかと思います） 前処理や後処理の書き⽅‧ヘルパーメソッドとの関わり
22. テストの出⼒結果もネストしていることがわか るように⼯夫する npx jest --verbose specs/src/regularRule/rules.spec.ts AwsServiceName validateFullName ✓ given a right prefix and a right service name, return True ✓ given a right prefix and a wrong service name, return False ✓ given a right prefix and a wrong service name, return False
23. 以上、今回はテストコードのタイトル付け（命 名）のお話でした
24. （未承諾広告）開発者テストについて情報発信 しています / していきます
25. まとめ BDDテストフレームワークでテストコードを書く時のタイトルの命名について 含めたい3つの情報 テストの対象 どんな時に（シナリオ or ⼊⼒） 期待する振る舞い これら情報の書き⽅ decribe などで構造化する test や it などに必要な情報を全て書く（できるだけ平坦にする） 書籍には test と it の使い分けについても記載がありますよ！
26. あなたはどちらのやり⽅が好きですか？
27. ご清聴ありがとうございまし た！