1 of 40

テストを書く負担を減らそうとしてる話

2 of 40

イントロダクション

00

3 of 40

00 目次

今日話すこと

  1. なぜテスト負担を減らすことを取り組もうと思ったか

​

  • テスト指針をチームで作る

​

  • 指針がチームに馴染むようにする

​

  • テストの見える化を進める

​

  • 俺の考えた超Rspec大全!!!!!!

​

​

​

​

3

4 of 40

なぜテスト負担を減らすことを取り組もうと思ったか

01 背景

5 of 40

01 なぜテスト負担を減らすことを取り組もうと思ったか

チームのテスト負担を減らそう！などとは思っていなかった…！

もともとの出発点はチームに足りていないものって何か？を考えるところからだった

​

    • 問
      • 明日から使える日々の開発知識をみんなで話せる場ってなくない？

�

5

明日から使える

将来使える

一人が話す

みんなで話す

読書会

勉強会

レビュー

6 of 40

01 なぜテスト負担を減らすことを取り組もうと思ったか

テストコードの書き方は課題にも感じていた

  • 関わっている人数も多く書き方がバラバラに感じた
    • 前に関わっていたサービスからの反動
      • 以前はテストコード規約を導入していた
      • 以前は人数も少なく共通意識を持てていた

​

  • 「テストを書くのが大変」という声も朝会でちょくちょく聞いた
    • ほぼ毎日書く機会があるから、ここ改善できると働く負担減らせられると思った

​

6

7 of 40

01 なぜテスト負担を減らすことを取り組もうと思ったか

Specディスカッション会爆誕👶 

7

8 of 40

01 なぜテスト負担を減らすことを取り組もうと思ったか

Specディスカッション会

  • なぜテストコードを書くのか？
    • 池田さんの基調講演
      • テストが仕様書になると良いよね
      • テストが書きにくい=実装がイケてないのでは？

​

  • 各々のテストに関する疑問や課題
    • 色々出たのでnotion参照
      • https://www.notion.so/campfirejp/2022-05-12-spec-f838d24274fe457aa24df840784e9e8c

​

8

9 of 40

01 なぜテスト負担を減らすことを取り組もうと思ったか

(specディスカッション会を経て) やっぱり指針があると良いなぁと思った

9

10 of 40

テスト指針をチームで作る

02 指針をつくる

11 of 40

02 テスト指針をチームで作る

何らかの指針 = ?

​

  • 各々の課題や疑問の言語化

​

  • 全員が持つ暗黙知や共通認識の明文化

​

=> これらを 0 から言語化するのは大変そう…

​

11

12 of 40

02 テスト指針をチームで作る

何らかの指針 = テスト規約 で良いのでは？

​

  • 各々の課題や疑問の言語化

​

  • 全員が持つ暗黙知や共通認識の明文化

​

=> テスト規約の輪読会を行うことで、

それぞれが持つ共通認識の再確認や課題の洗い出しが出来るのでは！？

​

12

13 of 40

01 なぜテスト負担を減らすことを取り組もうと思ったか

テストコード輪読会爆誕👶 

13

14 of 40

02 テスト指針をチームで作る

rspec-style-guide 

14

15 of 40

02 テスト指針をチームで作る

テストコード規約輪読会で取り上げた規約

​

  • describeとcontext
  • FactoryBotのデフォルト値
  • FactoryBotでbelongs_to以外の関連をデフォルトで作成しない
  • 日時を取り扱うテストを書く
  • beforeとlet(let!)の使い分け
  • letとlet!の使い分け
  • 控えめなDRY(shared_examplesはよく考えて使う)
  • スコープを考慮する
  • 必要ないレコードを作らない
  • updateでデータを変更しない
  • letを上書きしない
  • subjectを使うときの注意事項
  • allow_any_instance_ofを避ける

​

15

16 of 40

02 テスト指針をチームで作る

規約例: スコープを考慮する

​

​

​

​

​

​

16

17 of 40

02 テスト指針をチームで作る

まずは、規約ではなく指針として使う

​

  • 実装時やレビュー時に、各々が意識できるようにしていく

​

    • 指針があることで、コードを書くときの負担を長期的には減らせるはず
    • この過程でコードの書き方が統一されると認知コストも減らせるはず

​

​

17

18 of 40

指針がチームに馴染むようにする

03 指針を根付ける

19 of 40

03 指針がチームに馴染むようにする

指針を守るのは大変

​

​

  • 指針があるとしても、あくまで指針であって守るのは個々人

​

    • それでは結局属人化してしまうのでは？

​

=> 指針が指針足るような仕組みがあると良い

​

19

20 of 40

03 指針がチームに馴染むようにする

rubocop-rspec

20

21 of 40

03 指針がチームに馴染むようにする

現状を把握してみる①

​

$ bundle exec rubocop -a

​

​

21

22 of 40

03 指針がチームに馴染むようにする

現状を把握してみる②

​

$ bundle exec rubocop --auto-gen-config

=> 4608 files inspected, 26211 offenses detected

​

22

23 of 40

03 指針がチームに馴染むようにする

主な違反

​

​

  • RSpec/ContextWording
    • Offense count: 4671
    • contextはwhenで始まるようにしよう

​

  • RSpec/MultipleExpectations(max: 33)
    • Offense count: 1276
    • 一つのitではexpectをn個にしよう
  • RSpec/NestedGroups(max: 10)
    • Offense count: 4496
    • ネスト深すぎる
  • RSpec/LetSetup
    • Offense count: 940
    • letで定義してるけど定義したのが呼ばれてないよ

​

​

​

23

24 of 40

03 指針がチームに馴染むようにする

チームでルールを決めて運用していく

​

​

  • 現状のCAMPFIREのコードに則ったルールを決めていく
    • rubocop.ymlとrubocop_todo.ymlを整備しながらテストを成長させていく
      • rubocop.yml: 守るべきルール
      • rubocop_todo.yml: 直していくルール

​

​

​

​

24

25 of 40

テストの見える化を進める

04 見える化

26 of 40

04 テストの見える化を進める

書かれているテストはよくなった、では書かれていないテストは？

​

​

  • 書かれているテストがどんなに優れていても、テストが書かれていなければ意味がない

​

    • じゃあ ”とにかく” 積極的に網羅的にテストを書こう！

​

26

27 of 40

04 テストの見える化を進める

書かれているテストはよくなった、では書かれていないテストは？

​

​

  • 書かれているテストがどんなに優れていても、テストが書かれていなければ意味がない

​

    • じゃあ ”とにかく” 積極的に網羅的にテストを書こう！

​

=> みたいな根性論や属人化した考え方はなるべく減らしていきたい

​

27

28 of 40

04 テストの見える化を進める

simplecov

28

29 of 40

04 テストの見える化を進める

カバレッジの見える化をする①

​

  • すでに入っていた
    • ぴょんさん神👏

​

29

30 of 40

04 テストの見える化を進める

カバレッジの見える化をする②

​

  • 見方

​

30

31 of 40

04 テストの見える化を進める

カバレッジの見える化をする③

​

  • Models: 78.35%
    • googleの単体テストの網羅率が80%弱という話

​

31

32 of 40

04 テストの見える化を進める

カバレッジの持つ意味

​

  • 検知
    • 現在の状況把握
      • なんのテストが書かれていて、なんのテストが書かれていないかを明示的に把握する仕組み
        • サービスレベルとして重要な機能のテストが書かれていないなどを把握できる

​

  • 傾き
    • 定期的な観測
      • 2022年7月20日時点はこれだけカバレッジされていた、では一ヶ月前は？
        • 網羅率が高くなっている
          • 既存テストが追加された
          • 新規テストが書かれている
        • 低くなっている
          • ＼(^o^)／

​

32

33 of 40

04 テストの見える化を進める

カバレッジを高めていく取り組み

​

  • 不要なコードの削除

​

    • カバレッジを高めるために使われていないコードのテストを書くのは無駄

​

=> ただ、どのコードが使われていて、どのコードが使われていないのかを判断するのは難しい

​

​

33

34 of 40

04 テストの見える化を進める

coverband

34

35 of 40

04 テストの見える化を進める

coverband①

​

​

​

35

36 of 40

04 テストの見える化を進める

coverband②

​

​

​

36

37 of 40

04 テストの見える化を進める

テストまわりの改善を進めることでテスト以外の開発も捗る

​

  • 不要なコードの削除

​

    • 使われていないコードを削除することで、実装がシンプルになったり、影響範囲をへらすことも出来る

​

​

​

37

38 of 40

まとめ

05 まとめ

39 of 40

05 まとめ

テストを書く負担を減らせるようにするといろいろナイスな気がしてる

​

  • チームで技術に関して話す文化

​

    • specディスカッションやテストコード輪読会で、開発メンバーと技術に関して話せた
      • 開発共有MTGというチームで開発課題に関して話そうという場もできてる

​

  • テスト指針やコーディング規約に沿った開発
    • 指針に沿わないコード = 実装がイケていないのでは？
      • 実装を見直す機会にもある

​

​

=> 少しずつチームで良いテストやコードを書けるように進化して

みんなで良いサービスを作っていきたい！

39

40 of 40

ご清聴ありがとうございました🙌