テストコードを負債化させない上手な付き合い方 / Test Code Management

© 2024 Wantedly, Inc. テストコードを負債化させない上手な付き合い方 TechBrew in 東京〜技術的負債と共に歩むプロダクトの成長〜
Jan 25 2024 - Sora Ichigo

© 2024 Wantedly, Inc. 自己紹介名前市古空 (Sora Ichigo)
所属 • ウォンテッドリー株式会社 • 新規プロダクト開発チーム • DevOps 推進チームリード SNS • X: @igsr5_ • GitHub: @igsr5

© 2024 Wantedly, Inc. 今日の話「テストを書くだけで偉い」を卒業する書籍 XUnit Test Patterns
をベースに筆者の経験則を伝える http://xunitpatterns.com/

© 2024 Wantedly, Inc. スコープ内外 1. テストは品質向上に役立つべき 2. テストはテスト対象を理解するのに役立つべき 3.
テストはリスクを減らすものであるべき 4. テストは簡単に実行できるべき 5. テストは書きやすく保守しやすくあるべき 6. テストはシステムの進化において最小限のメンテナンスであるべきテスト自動化の目的 XUnit Test Patterns より筆者意訳 http://xunitpatterns.com/Goals%20of%20Test%20Automation.html

© 2024 Wantedly, Inc. スコープ内 1. テストは品質向上に役立つべき 2. テストはテスト対象を理解するのに役立つべき 3.
テストはリスクを減らすものであるべき 4. テストは簡単に実行できるべき 5. テストは書きやすく保守しやすくあるべき 6. テストはシステムの進化において最小限のメンテナンスであるべきテスト自動化の目的 XUnit Test Patterns より筆者意訳 http://xunitpatterns.com/Goals%20of%20Test%20Automation.html

© 2024 Wantedly, Inc. 先に結論書きやすく保守しやすいテストを書くためには落ちて喜べるテストを書こう 1. 落ちて喜べるテストは良いテスト 2.
落ちて喜べないテストは負債になる 3. 意図の明確化・重複排除・実行結果の最適化がテスト実装のコツ

© 2024 Wantedly, Inc. Agenda 1. 問題のあるテスト 2. 見分け方 3.
原因 4. 対処法

© 2024 Wantedly, Inc. テストが負債化するとは具体例 • 落ちても直し方が分からないテスト • なぜ落ちたか分からないテスト
• 落ちた時の修正に時間がかかるテスト • 偽陽性・偽陰性が高いテスト • 頻繁に変更が発生するテスト • モックが間違っているテスト • テスト自体がバグっているテスト • 実行が遅いテスト • 確率的に落ちるテスト • 何もしていないのに壊れるテスト • …etc

© 2024 Wantedly, Inc. 低品質なテストコードの見分け方は？喜べない • どう直せばいいんだ... • なぜか大量に落ちた...
• どこでエラーになってるんだ... 喜べる • これは見逃してた！ • 早くに気づけてよかった！ • やっぱり落ちるよね！テストが落ちて喜べるかどうか

© 2024 Wantedly, Inc. テスト失敗を喜べない原因は3つ 1. テストの意図が不透明 2. テストが重複している 3.
テストの失敗原因が結果に現れない

© 2024 Wantedly, Inc. Obscure Test 1. テストの意図が不透明 • 「どう直せばいいんだ...」のケース
• 書籍 XUnit Test Patterns では Obscure Test と呼ばれる 2. テストが重複している 3. テストの失敗原因が結果に現れない

© 2024 Wantedly, Inc. Test Code Duplication 1. テストの意図が不透明 2.
テストが重複している • 「なぜか大量に落ちた...」のケース • 書籍 XUnit Test Patterns では Test Code Duplication と呼ばれる 3. テストの失敗原因が結果に現れない

© 2024 Wantedly, Inc. Assertion Roulette 1. テストの意図が不透明 2. テストが重複している
3. テストの失敗原因が結果に現れない • 「どこでエラーになってるんだ...」のケース • 書籍 XUnit Test Patterns では Assertion Roulette と呼ばれる • ※ ただし正確には他にも原因あり (補足で後述)

© 2024 Wantedly, Inc. 工夫次第で問題は事前回避できる 1. 意図の明確化 2. 重複の排除 3.
実行結果の情報を増やす

© 2024 Wantedly, Inc. ① 何を確かめたいのか？を明確に示そう Bad コンテキスト不足・複雑・冗長なテストが問題になりやすい # Bad
コンテキスト不足かつ複雑 it 'successes' do # successes とは user = User.create(name: 'Alice', email: '[email protected]', password: 'secure123') User.confirm_email # 複雑 User.update_last_login_time expect(user).to be_valid # 本当に必要？ expect(user.email_confirmed?).to be true expect(user.last_login_time).to be_present end

© 2024 Wantedly, Inc. ① 何を確かめたいのか？を明確に示そう Good コンテキストが明確・シンプル・無駄のないテストを書くべき let(:verified_email) {
'[email protected]' } let(:user) { User.create(email: verified_email) } # Good 最低限の情報から意図が伝わる it 'confirms user email' do user.confirm_email expect(user.email_confirmed?).to be true end # Good 意味のある単位で分割する it 'updates last_login_time' do # ... end

© 2024 Wantedly, Inc. ② 同じ確認を2回以上繰り返しても意味がない Bad 重複したテストに対する変更は手間が大きい # Bad
モデルスペックで確認したことをコントローラースペックでも確かめる (バリデーション) describe 'POST #create' do it 'creates a new user' do post :create, params: { user: { name: 'Alice' } } expect(assigns(:user)).to be_valid # これはモデルのテスト end it 'does not create a user' do post :create, params: { user: { name: nil } } expect(assigns(:user)).not_to be_valid end end

© 2024 Wantedly, Inc. ② 同じ確認を2回以上繰り返しても意味がない Good テストの責務は漏れなくダブりなく # Good
コントローラーの責務に焦点を当てたテスト describe 'POST #create' do it 'redirects to the user page on successful creation' do allow_any_instance_of(User).to receive(:valid?).and_return(true) post :create, params: { user: { name: 'Alice' } } expect(response).to redirect_to(user_path(assigns(:user))) # コントローラーの責務 end it 'renders new template on failure' do allow_any_instance_of(User).to receive(:valid?).and_return(false) post :create, params: { user: { name: 'Alice' } } expect(response).to render_template(:new) end end

© 2024 Wantedly, Inc. ③ 1回のテスト実行から得られる情報を最大化しよう Bad テスト実行の学びが少ないと修正に時間がかかる # Bad
全ての行が落ちる場合、1行毎にしか気づけない it "creates a user with correct attributes" do user = create_user!(name: 'Alice', email: '[email protected]', age: 23) expect(user.name).to eq 'Alice' # ここで落ちると後続が実行されない! expect(user.email).to eq '[email protected]' # 全て誤りであれば3回テストを往復する必要がある expect(user.age).to eq 23 end

© 2024 Wantedly, Inc. ③ 1回のテスト実行から得られる情報を最大化しよう Good Defect Localization (失敗原因が自ずと判明する状態)を目指す
# Good 一つのテストケースで確かめる事柄を1つにする it "creates a user with correct name" do user = create_user!(name: 'Alice') expect(user.name).to eq 'Alice' end it "creates a user with correct email" do # 他のテストケース成否に関係なく実行される # ... end

© 2024 Wantedly, Inc. ③ 1回のテスト実行から得られる情報を最大化しよう Good Defect Localization (失敗原因が自ずと判明する状態)を目指す
# Good テストユーティリティを使う it "creates a user with correct attributes" do user = create_user!(name: 'Alice', email: '[email protected]', age: 23) expect(user).to have_attributes( # attributesの差分を1度に確認できる name: 'Alice', email: '[email protected]', age: 23 ) end

© 2024 Wantedly, Inc. まとめ書きやすく保守しやすいテストを書くためには落ちて喜べるテストを書こう 1. 落ちて喜べるテストは良いテスト 2.
落ちて喜べないテストは負債になる 3. 意図の明確化・重複排除・実行結果の最適化がテスト実装のコツ

© 2024 Wantedly, Inc. 補足 • 時間の関係で対処法は全て紹介しきれていません ◦ 残りは書籍 XUnit
Test Patterns の Test Smell > Cause を見ると良いです ◦ 例. Obscure Test > Cause: General Fixture • p.25 「どこでエラーになってるんだ...」については他にも原因がありえます ◦ Erratic Test (確率的に落ちる) ◦ Fragile Test (何もしてないのに壊れる) ◦ これらのケースは対処が特殊で話すと長いのであえて割愛

テストコードを負債化させない上手な付き合い方 / Test Code Management

テストコードを負債化させない上手な付き合い方 / Test Code Management

Transcript

More Decks by sora_ichigo

Featured