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

テストデータを貯めて感じたこと

 テストデータを貯めて感じたこと

Yoshiori SHOJI

August 22, 2023
Tweet

More Decks by Yoshiori SHOJI

Other Decks in Programming

Transcript

  1. テストデータを貯めて
    感じたこと
    〜テストの健全性とコンテキストに紐づく重要度〜
    Aug 2023 toRuby
    Presented by Yoshiori Shoji

    View full-size slide

  2. テストのデータを
    貯めている
    3

    View full-size slide

  3. ビルドのデータや、テスト実行結果の
    データなどいろいろなデータを僕たち
    は蓄積している。
    このデータをもっと活用できるので
    は?
    4

    View full-size slide

  4. 5
    コード一行だけ修正した。
    なんで全件テストを通す必要
    があるの??

    View full-size slide

  5. あなたはちょっとした修正で影響範囲
    はないと思っているかもしれない。
    でも、予想外の部分でエラーが出る可
    能性はある。
    6

    View full-size slide

  6. ではそのエラーが出る可能性は
    何%ですか?
    7

    View full-size slide

  7. 8
    あー、そのテストたまに失敗
    するから再実行してみて!

    View full-size slide

  8. ではそのたまに失敗する可能性は
    何%ですか?
    9

    View full-size slide

  9. テストの健全性
    10

    View full-size slide

  10. テストのデータを貯めて見えてきたもの

    不安定なテスト(Flaky Tests)
    変更がないのに成功したり失敗したりするテスト
    Googleですら全体の16%はFlakyだと言っている(多すぎん?)

    失敗したことがないテスト(Never Failing Tests)
    今まで失敗したことがないテスト

    時間掛かるテスト(Longest Tests)
    純粋にコスパ悪い

    良く失敗するテスト(Most Failed Tests)
    Flakyとは違い変更が無ければ結果は変わらないが、よく失敗する
    依存関係や変数が多すぎるのかもしれない 11
    11

    View full-size slide

  11. このへんがテストの健全性、
    つまりそのテストが有効かどうかに
    繋がっているのではないか?
    12

    View full-size slide

  12. 健全性を取り戻すための指針
    より良いテストコードを書く

    不安定なテスト(Flaky Tests)
    不安定指数が高いもの、解決方法は様々

    失敗したことがないテスト(Never Failing Tests)
    本当に必要か、他でテスト出来ていないか

    時間掛かるテスト(Longest Tests)
    これは全てに乗算で影響しそう

    良く失敗するテスト(Most Failed Tests)
    依存関係や変数を見直す。テストしないで良いこともテストしていない

    13
    13

    View full-size slide

  13. このへんを指針に
    テストの健全性を保つために
    たまにメンテナンスしたい
    14

    View full-size slide

  14. コンテキストによる
    テストの重要性
    15

    View full-size slide

  15. テストの
    重要度
    優先度が
    状況によって違う
    16

    View full-size slide

  16. テストの重要度?優先度?が
    状況によって違う
    みんなで共通認識持てるように下記のよう環境を想像して

    全部のテストを実行すると2時間かかる

    テストを実行するタイミングは2つ

    PullRequestレビュー時のテスト(pre-merge)
    ▶ いわゆるトピックブランチ

    リリース直前のテスト(post-merge)
    ▶ mainブランチとかreleaseブランチとか言われるやつ
    17
    17
    * 気になってモヤモヤしている人に先に伝えるとスモークテストについては後でちょっとだけ触れます

    View full-size slide

  17. PullRequestレビュー時のテスト
    テストの信頼度 < 時間

    今まで落ちたことがないテストとか実行する必要あんまりない

    時間がかかるテストもコスパ悪い

    単純に同じ失敗率なら10分かかるテスト1個より1分で終わ
    るテスト10個実行したい(失敗率とかわかるなら)

    壊れやすいテストもそれなりに有用

    もちろん時間との兼ね合いだけど

    不安定なテスト(Flaky Tests)はノイズ 18
    18

    View full-size slide

  18. リリース直前のテスト
    テストの信頼度 > 時間

    100%の信頼度が欲しい

    全てのテストを実行したい気持ちが強い
    ▶ ちょっと政治的だけどテストしたという事実が重要なことも
    ▶ 例: 金融系なのでお客さんの環境に出す前に確認をしたかが大事

    不安定なテスト(Flaky Tests)はノイズ
    19
    19

    View full-size slide

  19. という環境で
    PR時には実行したくないけど
    リリース時には実行して欲しいテスト
    とかある
    20

    View full-size slide

  20. 例: DBのRead-Write splittingのテスト

    特性

    このテストは最初にマージされてから失敗したことがない

    実際のDBを使うので1テストあたりにかかる時間は多い
    21
    21

    View full-size slide

  21. 例: DBのRead-Write splittingのテスト
    関係なさそうな場所の修正のとき例えば文言修正のPR

    PullRequestレビュー時のテスト

    実行しなくていい、数秒で終わるならまだしも時間のかか
    るテストだしコケたこと無いし時間の無駄

    リリース直前のテスト

    結構ロジックの根っこ部分なので必ずテストしておきたい

    壊れていない事を確認したい
    22
    22

    View full-size slide

  22. 例: DBのRead-Write splittingのテスト
    関係ある場所の修正のとき例えばsplitのロジック変更

    PullRequestレビュー時のテスト

    めっちゃ重要

    ただ、ローカルで絶対テストしてからpushしてる?

    だったらもしかしてPRでは実行しなくてよい?
    ▶ まぁ、流石に実行したい。人はミスするしローカルで実は違う奴テスト実行してた
    とかあるある
    ▶ シェルの履歴から実行してて実は違うの実行してたとか
    23
    23

    View full-size slide

  23. 100%コケるテストはわかりやすく邪魔
    だけど
    100%成功するテストもある意味ノイズ
    になりうる
    (今の例の関連していないPRのように)
    24

    View full-size slide

  24. 昔から所謂スモークテストとかサニ
    ティテストとかの概念はあった。
    受け入れテストの前に浅くとか一部と
    かテストしたい。ので人が選別して一
    部をテストしていた。
    25

    View full-size slide

  25. ここからCM
    26

    View full-size slide

  26. もっとハッキリ言うと
    失敗するテストだけ実行したい
    -> それLaunchableで出来るよ
    27
    広告

    View full-size slide

  27. 失敗するテストだけ
    実行するは誇大広告
    だけど、失敗率の高
    いテストを実行でき
    るので例えば10分テ
    ストすれば97%の信
    頼度ですよとか選択
    できる 28
    広告

    View full-size slide

  28. CMおわり
    29

    View full-size slide

  29. どのようなテストが
    良いテストなのか?
    (ここからまだ答えなく悩んでる話)
    30

    View full-size slide

  30. さて、状況によって優先度が違うのは
    理解した。
    だんだんテスト書くときも
    色々なことを意識するようになった。
    31

    View full-size slide

  31. 例えばよく失敗するテスト

    不安定なテスト(FlakyTest)とは違う

    何かしらの変更がないと結果は変わらない

    Flakyなテストは同じコミットハッシュで成功したり失敗し
    たりする

    依存関係が多いテストとも言える

    ちょっと変更するだけで失敗する

    テストに関連する変数が多い
    32
    32

    View full-size slide

  32. これは良いテスト?
    33

    View full-size slide

  33. 依存関係の大小への個人的想い
    依存関係の多いテスト ->基本嫌い
    依存関係の少ないテスト->素晴らしい
    34

    View full-size slide

  34. 依存関係の少ないテストは素晴らしい

    Unit test とか

    一つのことをテストする大事

    きちんと設計すれば依存少なく書ける

    美しいと感じる

    しかし別の場所を修正しているときは重要度低い

    その場所を弄っているとき以外は無駄なテストになりがち

    依存少なく書いていれば
    35
    35

    View full-size slide

  35. 例: メールアドレスをマスクする処理のロジックのテスト

    y*****[email protected] 的なやつ

    最初の実装時には絶対に書きたい

    例えば1文字の時とか2文字のときとかの境界値のテスト

    不安を元に書くテスト

    所謂 Development Test

    ここ以外を弄っているときはまず壊れない

    他の部分の修正のPRでは極論実行する価値がない
    36
    36

    View full-size slide

  36. 依存関係がそれなりにあるテスト
    ▶ もちろんすぐに壊れるようなテストはメンテコスト高すぎなので論外
    ▶ なんとなく俺の中ではRailsで言うController testくらいのやつ
    ▶ postアクセスしてアサインされている変数が適切かとか
    ▶ System testになるとちょっと壊れやすすぎな気がする
    ▶ 動作確認が面倒くさいから書くことが多い
    ▶ フォームの複数の項目により処理が色々変わるとか
    ▶ つまり変数が多い
    ▶ 毎回ブラウザでポチポチが面倒くさいからテスト書く
    37
    37

    View full-size slide

  37. 依存関係がそれなりにあるテスト

    どちらにしても僕個人としてはあまり美しさを感じない

    不安ではなく面倒くさいから書くテスト

    ユーザー影響ある時に適切に失敗するので役に立つ

    これは結構PullRequestのときも重要度高い

    もちろんリリース直前のときも重要度高い
    38
    38

    View full-size slide

  38. これは良いテスト? な気もする
    39

    View full-size slide

  39. 何となく僕の中でモヤモヤと下記が成り立ちつつある
    ▶ 不安を元に書くテスト
    ▶ 依存関係少ない
    ▶ 美しいと感じる
    ▶ 動作確認めんどくさいから書いたテスト
    ▶ 依存関係多め、変数多め
    ▶ 美しくないと感じる
    ▶ でもPullRequestの時とかは特に後者のほうが重要なことが多い
    ▶ 美しいと思ってないほうが重要なのでちょっと嫌悪感
    ▶ まぁしょうがないんだけど
    40
    40

    View full-size slide

  40. でもController Test落ちた時に
    原因箇所のUnit Testなかったら
    ムカつく!!!!
    41

    View full-size slide

  41. テストのデータを集めて色々やるの楽しい
    ▶ データを見るようになったことで今までテスト書いていた時に比べて
    重要度とか依存度とかを意識するようになった
    ▶ 書いたテストの健全性的な側面
    ▶ 時間とともに変わってくる
    ▶ 昔はそうでなかったものがFlakyになってきたり
    ▶ 見える化はとても良い
    ▶ それLaunchableで(ry
    ▶ 色々妄想捗る
    43
    43

    View full-size slide

  42. テストのデータを集めて色々やるの楽しい

    一方でまだモヤモヤ言語化出来ていないことも多い

    ピーキーなテストと適切に落ちるテストの境目とか

    あまり美しくないと思っているテストのほうが
    俺のことを助けているという事実とか

    開発時には美しいテスト助かってるのよ!!
    44
    44

    View full-size slide

  43. オチはなし!
    モヤモヤを吐き出しに来たので!
    45

    View full-size slide

  44. 最後に

    やっぱりSoftware TestingとかDevelopment Test
    とか楽しい

    今は趣味と仕事が一致していてとても楽しい

    一方で会社の業務と繋がってるとこういう話を出来る場
    所が少ない
    ▶ 会社の話が出るならスポンサーセッションでとか言われる

    ということで今日は本当にありがとうございます!!!
    46
    46

    View full-size slide

  45. Thank you!
    47

    View full-size slide