リーダブルテストコード〜メンテナンスしやすいテストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code

リーダブルテストコード〜メンテナンスしやすい　テストコードを作成する　方法を考える〜 1 #DevSumiB

はじめに 2

はじめに本セッションで扱うこと • 読みやすいテストコードについて • メンテナンスしやすいテストコードについて本セッションで扱わない（可能性が高い）こと • 自動テストの書き方 •
テスト駆動開発のやり方

登壇者の依頼経緯 • twadaさん：翻訳記事「【翻訳】テスト駆動開発の定義」を通じて、テストリストやTODOリストといった設計部分のステップの重要性について語っている • 末村さん：自著『テスト自動化実践ガイド』の中で「テストコードに意図を込める」という章を書いている
• 🥦：翻訳書籍『The BDD Books - Formulation』の中で、読みやすいテストシナリオについて語っている

各登壇者の立ち位置 Dev QA Unit E2E

アジェンダ • はじめに • twadaさんの発表 • 末村さんの発表 • 🥦の発表 •
パネルディスカッション • おわりに

twadaさんの発表 7

テストコードの認知負荷和田卓人 @t_wada

自己紹介和田卓人（わだたくと）プログラマ、テスト駆動開発者学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、 2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編
者。テストライブラリ power-assert-js 作者。 X(Twitter): @t_wada GitHub: @twada Bluesky: @twada

アンチパターン1：情報が少なすぎる

アンチパターン2：情報が多すぎる

課題外在性負荷を下げる: 名前、構造、情報量に気を配る https://gihyo.jp/dev/serial/01/savanna-letter/0007

課題外在性負荷を下げる: 名前、構造、情報量に気を配るテストの本体部分は、重要でない情報や紛らわしい情報は全く含まずに、テストを理解するのに必要な情報を全部含むべきである

末村さんの発表 14

AI powered Quality Engineering Platform 2024.06.20 コンテキストを明⽰してテストコードを⾃⼰説明的にしよう末村拓也
2024.9.18 AI powered Quality Engineering Platform

末村拓也 - Quality Evangelist at Autify - 倉庫内軽作業→Web開発者→QAエンジニア→テクニカルサポート→マーケター
- 品質・テスト周りの議論が好き自己紹介

E2Eテストコードは手続き的になりがち • いま、どのページにいるのか • いま、どんなデータがあるはずなのかこうした文脈=コンテキストが暗黙のうちに発生してしまうと認知負荷が高くなってしまうコンテキスト

// 店舗スタッフとしてログインする I.amOnPage("/"); I.click("ログインする"); I.fillField("ユーザー名", "admin"); I.fillField("パスワード", "admin"); I.click("ログイン") //
この後の処理は、暗黙に「店舗スタッフとしてログイン後」を期待されている I.click("スタッフ用マイページ") コンテキストが明示されない例 (1) ログイン状態

I.amStoreStaff( fn => { I.amOnPage("/"); I.click("ログインする"); I.fillField("ユーザー名", "admin"); I.fillField("パスワード", "admin");
I.click("ログイン") fn() }) ログイン状態に入る関数を作ってしまおう

// この中で実行される処理はログイン済み状態であるべき I.amStoreStaff( (I) => { // ... ここに店舗スタッフとして実行したい処理を書く I.click("スタッフ用マイページ")
}) ブロックの中はログイン状態なのが明確になる

// ここから商品一覧ページ I.amOnPage("/items"); const itemContainer = locate("tr").withText("トマト") I.click("商品を編集", itemContainer); //
ここから商品編集ページ I.fillField("商品名", "プチトマト"); I.click("変更"); // ここまで商品編集ページ // ここから商品一覧ページ同じ要領でページ遷移も

I.shouldBeOnItemListPage(I => { const itemContainer = locate('tr').withText("トマト") I.click("商品を編集", itemContainer(itemName)); I.shouldBeOnItemDetailPage(I
=> { I.fillField("商品名", "プチトマト"); I.click("変更"); }) }) 「あるページにいる」というコンテキストを表現する

// テスト用の商品を追加する I.click("商品を追加する"); const itemName = `牛ハラミ弁当-テスト-${utils.now.format("YYYYMMDDHHmmss")}`; I.fillField("商品名", itemName);
I.fillField("商品説明", "テスト用の商品です"); I.fillField("価格", "500"); I.click("追加"); データの準備も

// テスト用の商品があるという前提条件が重要であり、手順はどうでもいい const itemName = await I.haveItem() 「〜を持っている」というコンテキストを表現する

まとめ • E2Eテストは手続き的になりがち • コンテキストを明示するとコードが自己説明的になりコメントに頼る必要がなくなる

🥦の発表 26

テストコードにはテストの意図を込めよう（2025年版）ブロッコリー @nihonbuson

自己紹介 • 風間裕也（ブロッコリー） • 株式会社10X 品質管理チーム • 副業：B-Testing（個人事業主）として ◦ 株式会社MonotaRO
（テストコンサルタント） ◦ グロース・アーキテクチャ&チームス株式会社他数社でお手伝い • 社外活動 ◦ JaSST Review（ソフトウェアレビューシンポジウム）実行委員長 ◦ WACATE（テストの合宿型ワークショップ形式勉強会）実行委員長 ◦ SReEE（ソフトウェアレビューをエンジニアリングっぽく捉える会）リーダー SNS上のアイコン

翻訳書籍今日のメイン

テストコードをリーダブルにすることで上がる品質は何か？

リーダブルテストコードの効果リファクタリングはTDDの柱です。試験性（テスト容易性）はテストファーストが高めますが、修正性（変更容易性）はリファクタリングが高めます。保守しやすく変化に強いソフトウェアを支える柱　自動テストとテスト駆動開発、その全体像リーダブルなテストコードは修正性（変更容易性）を高める

理解容易性や説明容易性も重要なのでは？ • 理解容易性（Understandability） ◦ 対象の理解しやすい度合い ◦ 可読性（Readability）に影響を受ける • 説明容易性（説明可能性、Explainability） ◦
「今やっていることは何か」を説明できる度合い ◦ 読み手のコンテキストにも左右される ◦ 特にAI分野では「eXplainable AI(説明可能なAI)」として注目されている ◦ 可読性（Readability）に影響を受けるオリジナルの用語

保守性との関係保守性テスト容易性変更容易性説明容易性可読性が上がると、説明容易性や理解容易性が上がり、変更容易性やテスト容易性も上がり、保守性も上がる理解容易性可読性

会話を通じて説明容易性を上げた事例

お題と提示しているコードの注意点 • 10X（私が所属している会社）での在庫処理に関するテストケース • 10Xで扱っているプロダクトコードとテストコードに似たものをJavaの形で書き直したもの ◦ 実際のコードにはFlutterで記述している ◦
実際のコードはもっと設計がしっかりしています！ • 分かりやすさ・説明のしやすさ重視のため、実際のコードよりも処理を単純化して例示している

在庫処理のテストケース @Test public void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”);
productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); }

会話からテストの意図を理解する @Test public void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”);
productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc(), is(7) ); } これって  どうして最終的な  期待値が7なんですか？  えっとそれは…  QA 開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } まず、  商品Aのクラスを  生成して…  開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } 元々の在庫数の10個を  setBaseStockで  設定して…  開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } 新たに入庫された6個を  setReceivedStockで  設定するので、  合計の在庫は  10+6=16個で…  開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } 得られた在庫数は  実店舗とネットスーパー上  での共用となるので、  全体の在庫の50%を  ネットスーパー用に  確保するために、  setNsCoefficientで  設定するので、  16×0.5=8個となって…  開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } 最後に手動で設定する値  “setManualOverride”が  あれば、何があっても  ネットスーパーの  在庫数として  上書きされるので、  今回の在庫は7個に  なります。  開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } なるほどー！  ありがとうございます。  QA

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } QA 説明を聞いていると、  「setManualOverrideがあれば、  何があっても   ネットスーパーの   在庫数として   上書きされるので」   という部分が  今回のテストの意図の  ように聞こえました  ああ、確かにそうかも  開発者

テストの意図を記載して説明容易性を上げる @Test public void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”);
productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } なので、それを  そのまま  テストメソッド名に  しちゃいましょう！  QA

テストの意図を記載して説明容易性を上げる @Test public void 手動設定の値があれば必ず最終的な在庫数として上書き設定する { ProductStock productStock =
new ProductStock(“商品A”); productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } なので、それを  そのまま  テストメソッド名に  しちゃいましょう！  QA

余談：各職種の得意分野得意分野となる注目点が異なる • PO…今回のFeatureで実現したいことに注目 • 開発者…今回のFeatureはどのようにすれば　　　　実現できるかに注目 • QA…今回のFeatureが「完成した」と　　判断するためには
　　何を確認すれば良いのか（テストの意図）に注目 ※あくまでも得意分野であり、　責任分担している訳ではない

テストの意図をテストメソッド名に書くことの利点

利点1.特別な設定値がどれなのか分かる @Test public void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”);
productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } テストの意図が書かれていないと、テストメソッド内にある、 “10”, “6”, “0.5”, “7” がそれぞれ特別な意味を持っているように見えてしまう

利点1.特別な設定値がどれなのか分かるテストの意図が書かれていると、重要な箇所が分かるその他の値は、テストするために設定した任意の値だと分かる @Test public
void 手動設定の値があれば必ず最終的な在庫数として上書き設定する{ ProductStock productStock = new ProductStock(“商品A”); productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); }

利点2.仕様変更時に対応しやすい例えば、「手動設定 setManualOverride は考えなくても良いことになった」という仕様変更が出てきたとき… @Test public
void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”); productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); }

利点2.仕様変更時に対応しやすいプロダクトコードで setManualOverride() の処理を削除したとする連動して、このテストコードは通らなくなる @Test public

利点2.仕様変更時に対応しやすいテストの意図が書かれていないと、このテストがどんなことをしたかったのか改めて読み込む必要がある @Test public

利点2.仕様変更時に対応しやすいテストの意図が書かれていることで、今回はテストケースそのものを削除する対応で良いと即時に判断できる @Test public void
手動設定の値があれば必ず最終的な在庫数として上書き設定する{ ProductStock productStock = new ProductStock(“商品A”); productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); }

まとめ

まとめ • 何を確認したいテストなのか考えることが大切 • 会話を通じてテストの意図を見つけ出すことが可能 • テストの意図を明記しておくことで、 ◦ 理解容易性や説明容易性が上がる ◦
テストコードの修正性（変更容易性）が上がる

パネルディスカッション 57

議論1：それぞれの発表を聞いた感想 • 各発表の簡単なまとめ ◦ twadaさん…適度な情報量と名前や構造に気を配る ◦ 末村さん…コンテキストを明示する ◦ 🥦…テストの意図をテストメソッド名に示す •
共感した部分 • 少し考え方が違った部分 • 深掘りしたい部分

議論2：まず意識する部分は何か？ • テストコードを含むコードのレビュアーを想定 • 最初にどんな思考をするのか？ • 最初に確認する内容はどこか？ ◦ 指摘事項 ◦
レビュー作業の内容

議論3：セルフチェックできる要素は何か • テストコードを含むコードの作成者を想定 • リーダブルなテストコードを目指すために、自分自身でチェックできる項目は何か？ • 最初にAIにチェックを任せるとして、どんな点に注目してチェックをお願いするか？

議論：会場からの質問 • Slidoを見て答える

おわりに 62

本セッションの続きはJaSST Tokyoで！ • 同じ登壇者で3/28に登壇します。（イベント全体は3/27,28の2日間） • 会場はTODAホール＆カンファレンス東京 ◦ ＪＲ東京駅八重洲中央口から徒歩７分 ◦
銀座線京橋駅から徒歩３分 • 参加費 ◦ 会場参加：11,000円 ◦ オンライン参加：8,800円

末村さんのお知らせブースで販売しています声かけてくれたらサインします目印

🥦のお知らせ • 明日もB会場（ココ）で登壇します ◦ 明日2/14の12:40～13:20 ◦ 開発スピードは上がっている…品質はどうする？～スピードと品質を両立させるためのプロダクト開発の進め方とは～ •
CodeZine Academy ◦ 次回は3/14 ◦ オフライン開催

おしまい 66 ご清聴ありがとうございました！

リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #Dev...

リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code

More Decks by nihonbuson

Other Decks in Technology

Featured

Transcript

リーダブルテストコード〜メンテナンスしやすいテストコードを作成する方法を考える〜 #Dev...

リーダブルテストコード〜メンテナンスしやすいテストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code