Upgrade to Pro — share decks privately, control downloads, hide ads and more …

テストコードにはテストの意図を込めよう #vstat

テストコードにはテストの意図を込めよう #vstat

nihonbuson

July 27, 2022
Tweet

More Decks by nihonbuson

Other Decks in Technology

Transcript

  1. 自己紹介 • 風間裕也(ブロッコリー) • 株式会社ビズリーチ(Visionalグループ) プロダクト品質管理部 • 社外活動 ◦ JaSST

    Review実行委員長 ◦ WACATE実行委員 • 執筆活動 ◦ 『Agile Testing Condensed』(翻訳) ◦ 『Testing in DevOps』(翻訳) ◦ 『The BDD Books Discovery』(翻訳) ◦ 『テストコードの注入から始める レガシーコードのリファクタリング』(技術同人誌) SNS上の アイコン
  2. Three Amigosの得意分野 Three Amigosは得意分野となる注目点が異なる • PO…今回のFeatureで実現したいことに注目 • 開発者…今回のFeatureはどのようにすれば     実現できるかに注目 •

    QA…今回のFeatureが「完成した」と   判断するためには   何を確認すれば良いのかに注目 ※あくまでも得意分野であり、  責任分担している訳ではない
  3. 3つの事例 • 本発表では、QAの得意分野である 「何を確認すれば良いのか」に 注目して行った会話を3つ紹介する ◦ 事例1:分かりやすいメソッド名を考える ◦ 事例2:テストの意図をテストメソッド名に反映する ◦

    事例3:会話を通じてテストの意図を見つけ出す ※本発表では「テストの意図」と表現していますが、  この言葉は、JSTQB(ISTQB)におけるテスト条件のことを指しています。  詳しくは、ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03  を参照してください。
  4. 何を確認したいテスト? これって
 47都道府県
 全てで
 テストする?
 QA 開発者 地方ごとに
 送料が
 変わるのが


    確認できれば
 OK!
 @Test public void _青森県の場合送料が1000円{ } @Test public void _広島県の場合送料が510円{ }
  5. 意図が伝わるテストメソッド名の例 @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test public

    void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); } ハイレベルテストケース ローレベルテストケース
  6. 意図が伝わるテストメソッド名の例 @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test public

    void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); } ハイレベルテストケース ローレベルテストケース 将来万が一、青森県が統廃合などで 存在しなくなった場合、 東北地方の別の県を選べば良いことが分かる
  7. 特別な意図があったのは一部分だけだった @Test /*氏名:テスト太郎、人数:0名、予約番号:印刷する*/ public void _テストその1{ @Test /*氏名:テスト太郎、人数:1名、予約番号:印刷する*/ public void

    _テストその2{ @Test /*氏名:テスト太郎、人数:2名、予約番号:印刷しない*/ public void _テストその3{ テストコードを 実装するために 必要になった 入力値
  8. Nestedを用いてテストの意図を整理する @Nested class _予約できる人数は1名以上4名以下 { @Test public void _人数が0名の場合予約できない{ @Test

    public void _人数が1名の場合予約できる{ } @Test public void _予約番号を印刷しない場合予約できる{
  9. お題その3 • 題材は自動販売機 • Cucumber + JUnit • 与えられた要求は下記の3つ ◦

    100円硬貨を入れたら 入金額が100円になってほしい ◦ 100円硬貨を入れた後に50円硬貨を入れたら 入金額が150円になってほしい ◦ 1円硬貨は対応しないでほしい
  10. お題を元に作成した結果(JUnitは割愛) Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:

    入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている public class VendingMachine { int currentMoney = 0; public void insertCoin(int money) { if (money == 50 || money==100) { currentMoney += money; } } public int getCurrentMoney() { return currentMoney; } }
  11. テストシナリオをさらに改善する Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:

    入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている
  12. シナリオ名を変更する Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:

    入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている すべてシナリオ名が
 『入金額確認』になってますね。
 同じ名前はどうかと思うので
 変えたほうが良い気がしてます。
 なるほど。
 そしたらこんな感じですかね。
 (テストシナリオを編集する)
 QA 開発者
  13. シナリオ名を変更する すべてシナリオ名が
 『入金額確認』になってますね。
 同じ名前はどうかと思うので
 変えたほうが良い気がしてます。
 なるほど。
 そしたらこんな感じですかね。
 (テストシナリオを編集する)
 Scenario: 1回投入時の入金額確認

    Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている QA 開発者
  14. テストの意図を明確にする Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:

    2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている なるほど。ちなみに、
 2つ目のテストの意図って
 なんですかね?
 コインを1回だけではなく、
 2回投入した時にも
 ちゃんと動くか確認したい
 という意図です。
 QA 開発者
  15. テストの意図を明確にする Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:

    2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている なるほどー。
 そしたら『2回投入時』と
 書いていますが、
 3回目はどうなるのでしょうか?
 3回目は2回目と同じく、
 加算されていく仕組みなので、
 ロジック上は大丈夫です。
 QA 開発者
  16. テストの意図を明確にする Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:

    2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている ということは、気にしているのは
 2回投入の金額ではなく、
 複数回の投入時の加算
 なんですね。
 あー、確かにそうですね。
 (テストシナリオを編集する)
 QA 開発者
  17. テストの意図を明確にする ということは、気にしているのは
 2回投入の金額ではなく、
 複数回の投入時の加算
 なんですね。
 あー、確かにそうですね。
 (テストシナリオを編集する)
 Scenario: 1回投入時の入金額確認 Given

    自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 複数回投入時の入金加算額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている QA 開発者
  18. 数年後、テストの意図が分かるのはどっち? Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:

    入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 複数回投入時の入金加算額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている
  19. おわりに • 今回は、テストメソッド名に着目して、 テストの意図が伝わる改善例をお伝えしました。 • 実際には、テストの意図を確認した結果、 そもそも実装しているテストが 良くない形になっている場合もあります。 ◦ その際はテストメソッド内のリファクタリングや

    テスト設計の作り直しをします。 • 今回は会話から改善する例をお伝えしましたが、 初めからテストプロセスを意識してテストケースを作成 することで、メンテナンス性を高めることができます。
  20. テストプロセス(JSTQBより) テスト 分析 テスト 設計 テスト 実装 テスト 実行 ISTQBテスト技術者資格制度

    Foundation Level シラバス 日本語版 Version 2018V3.1.J03 を参考に作成 何をテスト するか を決定する テストスクリプト やテスト手順を 作成する テストスイート を実行する どのように テストするか を決定する
  21. テストプロセス テスト 分析 テスト 設計 テスト 実装 テスト 実行 何をテスト

    するか を決定する テストスクリプト やテスト手順を 作成する テストスイート を実行する どのように テストするか を決定する ここを 注力しがち ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 を参考に作成
  22. テストプロセス テスト 分析 テスト 設計 テスト 実装 テスト 実行 何をテスト

    するか を決定する テストスクリプト やテスト手順を 作成する テストスイート を実行する どのように テストするか を決定する ここからテストの 意図を込めましょう ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 を参考に作成
  23. 翻訳書 『Agile Testing Condensed』 • Janet Gregory, Lisa Crispin著 •

    販売:Leanpub • 電子書籍として発売中 • 2019年9月発行 • 2020年4月翻訳版発行 Agileな開発の中で どのようにテストを考えれば良いか について簡潔に書いている一冊 Agile Testing Condensed
  24. 翻訳書 『A Practical Guide to  Testing in DevOps』 • Katrina

    Clokie著 • 風間 裕也、河原田 政典 訳 • 販売:Leanpub • 電子書籍として発売中 • 2017年8月発行 • 2021年8月翻訳版発行 DevOpsにおけるテストについて 事例を交えて紹介した一冊 A Practical Guide to Testing in DevOps
  25. 翻訳書 『The BDD Books - Discovery』 • Gáspár Nagy, Seb

    Rose著 • 販売:Leanpub • 電子書籍として発売中 ◦ もうすぐ物理本を出せるかも? • 2018年2月発行 • 2022年5月翻訳版発行 BDDやATDDにおける、自動化する前の 第1ステップについて書いている一冊 The BDD Books - Discovery
  26. 著書(技術同人誌) 『テストコードの注入から始める  レガシーコードのリファクタリング』 • 販売:Leanpub • 電子書籍として発売中 ◦ ライブコーディングビデオ付き •

    2021年7月発行 テストコードを少しずつ注入しながら、 レガシーコードに立ち向かう方法を、 実際のテストコードを記載しつつ 説明している一冊 テストコードの注入から始める レガシーコードのリファクタリング
  27. 参考:BRIEFの原則 • Business language(ビジネス言語) • Real data(実際のデータ) • Intention revealing

     (意図を明らかにする) • Essential(必須) • Focused(焦点を絞る) • Brief(簡潔である) 参考:The BDD Books - Formulation