書きながら考えないRSpec

Transcript

1. © Tsukulink Inc. 書きながら考えないRSpec

2. 自己紹介 
 なまへ：にしむらてつ
 趣味：スノーボード、クライミング、スキューバダイビング
 すんでるとこ：長野県
 おしごと：Webエンジニア（ツクリンクでは非機能面の改善を担当）
 好きな言語・技術：Rust, TypeScript, TCP/IP(Routing, Swiching, QoS)

3. リリース
 テスト
 テストコードはいつ書きはじめてますか？ 
 実装
 設計
 要件定義

4. リリース
 テスト
 テストコードはいつ書きはじめてますか？ 
 
 実装
 設計
 要件定義
 さすがに早すぎ
 かけそう？
 TDD
 多そう
 🔥🔥🔥

5. リリース
 テスト
 テストコードはいつ書きはじめてますか？ 
 
 実装
 設計
 要件定義
 さすがに早すぎ
 どっすか？
 TDD
 多そう
 🔥🔥🔥

6. テスト設計やってみませんか 

7. テスト項目書いてみよう 
 あなたは「りんご銀行」ATMのテスト担当者です。 
 「りんご銀行」に口座を持っているお客様のATM引き出し手数料（以下、「手数料」）の条件は下記のとおりです。 
 • 平日の0:00～8:44は手数料が110円です。 
 • 平日の8:45～17:59は手数料が0円です。 
 • 平日の18:00～23:59は手数料が110円です。 
 • 土日祝日は終日手数料が110円です。 
 • 特別会員　のお客様は曜日や時間に限らず手数料が0円です。 
 手数料の出力を保証するために、どのようなテストケースが必要？　 　　　　　　　　　　　　　　　　　　　　 
 ※「ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～」 より抜粋 

9. テスト技法 

10. テスト技法どうですか 
 テスト技法：ソフトウェアテストのテストケースを作成するための技法
 1. テスト漏れを防げる 
 • テスト技法を使うことで、条件や組み合わせを網羅的に洗い出せる
 2. 曖昧な要件が明確になる 
 • テストケースを設計する過程で、どの条件でどの結果になるべきかを明示的に考える必要がある ため、要件が整理される
 3. テストの信頼性が向上する 
 • 系統立ったアプローチでテストケースを設計するため、手探りで作ったテストよりも一貫性と正確性 が高くなる

11. テスト技法のひとつ：デシジョンテーブルをためしてみる 
 
 デシジョンテーブル
 条件とそれに対応するアクションを整理・網羅的にテストケースにする手法。
 条件とその組み合わせを表形式で表します。
 無料で使えるツール • デシジョンテーブル作成支援ツール（β版） ◦ https://testcase-tool.vercel.app/decision_table • GIHOZ ◦ https://gihoz.com/ 参考「デシジョンテーブルテスト」テスト技法解説 https://www.veriserve.co.jp/helloqualityworld/media/20240125002/
12. あなたは「りんご銀行」ATMのテスト担当者です。 「りんご銀 行」に口座を持っているお客様のATM引き出し手数料（以下、 「手数料」）の条件は下記のとおりです。 
 • 平日の0:00～8:44は手数料が110円です。 
 • 平日の8:45～17:59は手数料が0円です。 
 • 平日の18:00～23:59は手数料が110円です。 
 • 土日祝日は終日手数料が110円です。 
 • 特別会員のお客様は曜日や時間に限らず手数料が0 円です。
 デシジョンテーブルの条件を整理 
 

13. デシジョンテーブル作成 

14. デシジョンテーブル作成 

15. デシジョンテーブルからテストケース一覧を出力 
 

16. RSpecのコードにおとすとこうなる
 • セルフチェック漏れできる
 ◦ ここで適当なspecファイルにしてcommitもあり
 ◦ itの中身を { expect(true).to eq false }にして
 failsさせるなど

17. RSpecのコードにおとすとこうなる
 だいたいcontext → ビジネスロジックの最小単位
 であることがおおいのでコードにも落としやすい、かも。

18. あらためて... 
 • 要件定義
 • 設計
 ◦ context単位はここで書いたほうがよくないすか 
 • 実装
 • テスト
 • リリース

19. 他のテスト技法 
 • ペアワイズ法
 • 状態遷移図
 • 境界値分析と同値分割
 参考になりますよ ソフトウェアテスト技法練習帳 ~知識を経験に変える 40問~
20. もちろん万能ではない 
 - デシジョンテーブルは記載した条件の妥当性までは確認できない 
 - 要件が不明確なまま取り掛かると十分に発揮できない
 - あくまでテストケースの網羅であり、どの種類のRSpecにするかはタッチしない 
 Request spec or Model spec, View spec …
 - ちがう技法・手法を採用すべきだった
 
 キレイなコードを保証するものではない。あくまで条件と動作の整理 
 便利なテスト設計のツールがあっても、設計スキルは必要 
 
 それでも実装に進む前に設計したほうがいいよ、
 と同じくらいには成果に差がでると思います。

21. ありがとうございました