Slide 1

Slide 1 text

あなたはどっち派? XSpec系テストフレームワークの構造 化流派について 2024年7⽉16⽇

Slide 2

Slide 2 text

⾃⼰紹介 名前: bun (今泉⼤樹) 所属: (今⽉転職しました) 認定試験 AWS認定試験12種 JSTQB(ソフトウェアテスト技術者の試験) Advanced Level Test Manager / Test Analyst / Technical Test Analyst 最近の悩み 新しい職場でロボットが出てくるアニメをよく勧 められる(ロボ顔) 本当はスポーツ物も好きだったりする ~ Japan AWS Top Engineer(Services)

Slide 3

Slide 3 text

ユニットテスト/インテグレーションテスト書い てますか?

Slide 4

Slide 4 text

私はXSpec(XUnit)⾵な記法ができるテスティングフレー ムワークが好きです Jest / Vitest Rspec Cucmber などなど

Slide 5

Slide 5 text

今回はとある洋書を読んで明確になってきた私なりのテスト コードの書き⽅のTIPSについて話します

Slide 6

Slide 6 text

The Art of Unit Testing Third Edition 作者: Roy Osherove / Vladimir Khorikov Vladimir Khorikov さんは 邦題: 「単体テストの考え⽅/使い⽅」の作者さんです 書籍のコードは JS / TS / Jest でWeb系のエンジニアでもとっつきやすいです

Slide 7

Slide 7 text

1.テストのタイトルに 含める情報は? 必要な情報が伝わるタイトルってなんだろう?

Slide 8

Slide 8 text

タイトルに含めたい3つの情報

Slide 9

Slide 9 text

1: テストの対象(SUT)

Slide 10

Slide 10 text

2: どんな時に(シナリオ or ⼊⼒)

Slide 11

Slide 11 text

3: 期待する振る舞い

Slide 12

Slide 12 text

「期待する振る舞い」を検証しようっ て良く聞きますよね 「単体テストの考え⽅ / 使い⽅」でもよくこのように表現される こうすればテスト対象の最終的な振る舞いを変えずにリファクタリングしても、テストは 壊れないとか 逆にテスト対象の振る舞いが変わったらちゃんとテストは失敗して、欲しいフィードバ ックをくれたりとか 例えば「この名前の関数が呼ばれた」などの内部の実装に紐づいていると振る舞いは 変わってないのにテストは失敗する メリットや背景から説明してくれる良書なのでぜひ読んでください

Slide 13

Slide 13 text

さておき‧‧‧命名やタイトルに⼊れたい情報 はOK

Slide 14

Slide 14 text

じゃあどうやって?(どこに?)

Slide 15

Slide 15 text

2.よく⾒る書き⽅の流 派 ⼤きく分けて2つの流派をよく⾒かける(感想)

Slide 16

Slide 16 text

: describe や context を使って構造化しよう ぜ派 サンプルコード参考(ほぼ引⽤): https://www.artofunittesting.com/

Slide 17

Slide 17 text

2: 極⼒ネストせず平坦にしようぜ派 サンプルコード参考(ほぼ引⽤): https://www.artofunittesting.com/

Slide 18

Slide 18 text

ちなみに‧‧‧ " テスト対象(SUT ), シナリオ or ⼊⼒, 期待する振る舞い" という書き⽅は書籍のレビュー中に Tyler Lemke さんから 教えてもらったとのこと 作者も気に⼊られたようで書籍中にこのような⼀⽂が出て来ます カンマ区切りで必要な情報が必要な形式で含まれてて良さそうですよね

Slide 19

Slide 19 text

(感じている)メリット / デメリット メリット デメリット : describe とかで構造化 ⼀⽂が短くなるし、構造化できる こと⾃体がメリット 複数の振る舞いをまとめたり テストが⼤きくなってくると、レビ ューが若⼲しにくくなることも 気をつけないと、何でもかんでもま とめられてしまうなど いけてないネストの深さ 前処理‧後処理を共通化して無 駄に状態を共有 2: できるだけ平坦に派 変更箇所とテストコードのレビュ ー必要箇所がほぼ⼀致 あまりスクロールを要しない 必然的に⼀⽂の⽂章は⻑い 構造化で感じる恩恵を感じられな いこと

Slide 20

Slide 20 text

書籍の作者さんとしては ⼀部の⼈は describe などで構造化することを嫌うだろうけど、ある種のエレガンスを感じるという(控えめな?)表 現をされている 3つの重要な情報をそれぞれのレベルに分けることができる

Slide 21

Slide 21 text

ちなみに私も基本的には構造化したい そもそも describe とかってそのためにできたのではと思う(未調査) テスト結果を⾒て⾮技術者の⽅でも条件や、その時の振る舞いをパッとわかるようになってたり ただ注意したいこともある describe のネストが深すぎて何をしているかよくわからなくなったり 何でもかんでも「まとめたほうがいいんだ!DRY!DRY」みたいに、 beforeEach などの前処理や後処理にまとめ られ上下へのスクロールを強制されたり 使う時には事前にチームでルールについて合意しておきたい(ふんわりでもいいので) ネストは深くしすぎない(2 か 3 までかと思います) 前処理や後処理の書き⽅‧ヘルパーメソッドとの関わり

Slide 22

Slide 22 text

テストの出⼒結果もネストしていることがわか るように⼯夫する 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

Slide 23

Slide 23 text

以上、今回はテストコードのタイトル付け(命 名)のお話でした

Slide 24

Slide 24 text

(未承諾広告)開発者テストについて情報発信 しています / していきます

Slide 25

Slide 25 text

まとめ BDDテストフレームワークでテストコードを書く時のタイトルの命名について 含めたい3つの情報 テストの対象 どんな時に(シナリオ or ⼊⼒) 期待する振る舞い これら情報の書き⽅ decribe などで構造化する test や it などに必要な情報を全て書く(できるだけ平坦にする) 書籍には test と it の使い分けについても記載がありますよ!

Slide 26

Slide 26 text

あなたはどちらのやり⽅が好きですか?

Slide 27

Slide 27 text

ご清聴ありがとうございまし た!