テストコード未経験者が RailsでそれなりにRSpecがかけるようになるまでの話 /Inexperience Rails developer ,Use Rspec

銀座Rails #6 にて登壇した際のスライドです。
https://ginza-rails.connpass.com/event/112094/

発表内に関しての話は下記
https://shinkufencer.hateblo.jp/entry/2019/02/22/235900

Transcript

1. テストコード未経験者が RailsでそれなりにRspecが かけるようになるまでの話 銀座Rails #6
2. 2 https://twitter.com/yoshi_hirano/status/1092275495771750400
3. 3 初学者向けのテストコードの書き方や テストコードをチームで取り組む みたいな話は見るが テストコードを書いてこなかった人が テストコードを書くようになった話 みたいのが ありそうであんまりない
4. 4 それなりにシステム開発してるけど テストコードを書いたこと無いひとが… • 書くようになるまでには • 書き出した人が進む階段 • 書き初めてつまずく場所 みたいなものを 自分の体験談をベースに 話していければと思っています
5. しんくう 最近はRailsエンジニアとか 開発の交通整理とか 2009年から3社ぐらい ソフトウェア開発を 続けてきてました。 守備範囲は浅く広く。 Twitter : @shinkufencer 5 自己紹介
6. 6 自己紹介 Webアプリケーション開発者から見た、 MVCとMVP、そしてMVVMの違い - Qiita https://qiita.com/shinkuFencer/items/f2651073fb71416b6cd7
7. 7 今日のもくじ 1. これまでの私と直前のステータス 2. Rspecと向き合うきっかけ、下準備 3. Rspecを使うなかでぶつかった小さな壁 4. そして今
8. 8 これまでの私と直前のステータス
9. 9 プログラマとしてやってきたもの • Ruby on Rails (2.0) • Flash Lite 1.1 • ActionScript 3.0 • C#(Unity) • Java (Android) • PHP (7.x)
10. 10 プログラマとしてやってきたもの • Ruby on Rails (2.0) • Flash Lite • ActionScript 3.0 • C#(Unity) • Java (Android) • PHP (7.x) これだけやっているのに テストコードを書く機会に 触れていない
11. 11 プログラマとしてやってきたもの • Ruby on Rails (2.0) • Flash Lite 1.1 • ActionScript 3.0 • C#(Unity) • Java (Android) • PHP (7.x) 元々テストコードを書く 文化がなく テストコード？って何？ というような環境だった 基本は人力のQAで デバッグしており そこで品質担保を 行っていた
12. 12 プログラマとしてやってきたもの • Ruby on Rails (2.0) • Flash Lite 1.1 • ActionScript 3.0 • C#(Unity) • Java (Android) • PHP (7.x) Flash Liteでは記述が 軽量化を重視するので テスト向けの実装が しにくい ActionScript 3.0も テストコードを書かない 文化圏でやっていたので 書くという発想がない
13. 13 プログラマとしてやってきたもの • Ruby on Rails (2.0) • Flash Lite 1.1 • ActionScript 3.0 • C#(Unity) • Java (Android) • PHP (7.x) ゲーム開発において テストコードを書く 事例があまりなく 書いてこない文化も 相まって書かなかった ※ゲームでも書くところ はちゃんとかいてます
14. 14 プログラマとしてやってきたもの • Ruby on Rails (2.0) • Flash Lite 1.1 • ActionScript 3.0 • C#(Unity) • Java (Android) • PHP (7.x) 1人プロジェクトだった ので各種テストフレーム ワークを使おうと思った のですが挫折 納期もタイトだったので ひたすら人力でテストし て難を逃れる
15. 15 プログラマとしてやってきたもの • Ruby on Rails (2.0) • Flash Lite 1.1 • ActionScript 3.0 • C#(Unity) • Java (Android) • PHP (7.x) チーム的にテストコード に対しての意識が薄く 書かないほうが開発の スタンダードだった 自分も書いてはいない 出自だったので書かずに 過ごしてきた
16. 16 いままでのテストコードの感覚 • はじめての会社はテストコードというもの を扱う文化がなかった • テスターメンバーが充実 + 優秀だったので 人力テストでバグは潰せたし 自身も念入りに手でデバッグしていた。 • 「テストは大事である」 という意識が芽生えたあとでも やるだけの工数捻出ができない 定石がわからないので、踏み切れなかった
17. 17 そしていろいろなものを経て • Ruby on Rails (2.0) • Flash Lite 1.1 • ActionScript 3.0 • C#(Unity) • Java (Android) • PHP (7.x) • Ruby on Rails (5.x) イマココ！
18. 18 Rspecと 向き合うきっかけ、下準備
19. 某日 19
20. 20 APIの案件があるので よろしくおねがいします。 企画の人
21. 21 APIの案件があるので よろしくおねがいします。 はい、Railsでやります 企画の人 わたし
22. 22 APIの案件があるので よろしくおねがいします。 はい、Railsでやります 企画の人 わたし 企画の人 ちょっとさまざまな理由で しばらくは開発1人体制で お願いします。
23. 23 APIの案件があるので よろしくおねがいします。 はい、Railsでやります 企画の人 わたし 企画の人 ちょっとさまざまな理由で しばらくは開発1人体制で お願いします。 あ、外部のAPIと接続予定 もあるので忘れずに！
24. 24 特殊なプロジェクトにアサイン • APIサーバの開発だけれど様々な要因で しばらくは1人で開発。 • 他のAPIなどとも接続するが、接続可能に なるのは開発期間の後半。 • 利用側の事由で仕様が変わる可能性がかな りあった。 • 企画側が練り上がるまで時間かかるので ほかの案件と並走。
25. 25 わたし APIだから開発ボリュームは少 ないけど先方のAPI接続とかは 人力テストがしにくい
26. 26 わたし APIだから開発ボリュームは少 ないけど先方のAPI接続とかは 人力テストがしにくい 急に仕様が変わったりするか もしれないから変更がおおい かもしれない
27. 27 わたし APIだから開発ボリュームは少 ないけど先方のAPI接続とかは 人力テストがしにくい でも後から入ったメンバーに 混乱がないようにしなければ つらくなる 急に仕様が変わったりするか もしれないから変更がおおい かもしれない
28. 28 わたし APIだから開発ボリュームは少 ないけど先方のAPI接続とかは 人力テストがしにくい でも後から入ったメンバーに 混乱がないようにしなければ つらくなる そのためにちゃんとするには どうすれば… 急に仕様が変わったりするか もしれないから変更がおおい かもしれない
29. 29 とある資料を思い出す ふつうのRailsアプリケーション開発 https://www.slideshare.net/takafumionaka/rails-77195340
30. 30 とある資料を思い出す ふつうのRailsアプリケーション開発 https://www.slideshare.net/takafumionaka/rails-77195340
31. 31 足回りを整える • 既存プロジェクトも足回りが整っていない 案件が多かったのでこれを期に整理
32. 32 足回りを整える • いままではgithubのreadmeに書かれた 手順を実行する形式だったので bin/setup,bin/updateに可能な限り纏める • 今後の新規プロジェクトはRspecのルール を統一できるようにrspec.ymlをgem化 • 新規のModelとControllerには必ずRspec を書くようにする • 他プロジェクトでCircleCIは使っていたの でRspecとrubocopが失敗したらCI失敗と みなす当たり前を敷く
33. 33 わたし CIがちゃんと活用できる仕組 みは整った。
34. 34 わたし CIがちゃんと活用できる仕組 みは整った。 ただRspecを書く足回りが整え られていないので整えなけれ ば！
35. 35 自身のRspec知識の足回りを整える • 既存のRspecを参考にするにはベースの知 識が足りない、基礎を抑えてたい。 • 伊藤淳一さんシリーズを活用する。 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita https://qiita.com/jnchito/items/42193d066bd61c740612
36. 36 自身のRspec知識の足回りを整える • Rails関連の知識はカバーできなかったので 同じく伊藤さんの翻訳書籍をさらっと読ん でカバー Everyday Rails - RspecによるRailsテスト入門 Aaron Sumner 著 et al. [Leanpub PDF/iPad/Kindle] https://leanpub.com/everydayrailsrspec-jp
37. 37 わたし Rspecの書き方はわかったので あとは実際に書きながら 研鑽してくしかない！
38. 38 わたし 今回はAPIだし 一番書くのはきっと Request specだろう Rspecの書き方はわかったので あとは実際に書きながら 研鑽してくしかない！
39. 39 わたし 今回はAPIだし 一番書くのはきっと Request specだろう そういえば他のプロジェクト で書いていたから 参考にしよう！ Rspecの書き方はわかったので あとは実際に書きながら 研鑽してくしかない！
40. 40 最初にみた既存コード ※実際のコードに似せて作ってあり、実際とは異なります
41. 41 最初にみた既存コード わたし createって、Rspecの構文？ それともそういうメソッドが 実はRailsにある？ ※実際のコードに似せて作ってあり、実際とは異なります
42. 42 最初にみた既存コード わたし インスタンス変数にいれてる これはrequest specのお作法 なのかな…？ ※実際のコードに似せて作ってあり、実際とは異なります
43. 43 最初にみた既存コード わたし 知識の少なさから混乱 右往左往しはじめる
44. 44 Rspecを使うなかで ぶつかった小さな壁
45. 45 ここからは 「事前に知っておいたら〜！」 とか 「独学だと気づきにくい…」 のような話をしていきます
46. 46 create(:モデル名） • FactoryBotというものの存在を知らない のでActiveRecordの便利機能か何かと勘 違い、createだからググラビリティも低い • 既存コードを書いたメンバーから FactoryBotということを教えられる • 自分で書く時は以下のように書くようにし ている。
47. 47 let!とbeforeインスタンス変数 • 基本的に既存定義はlet!を使う事例ばかり で、インスタンス変数を使うメリットが見 当たらなかった • 実際使わなくても問題ないということを知 り、基本は使わないように。
48. 48 require 'rails_helper' • お約束のrequireだと思っていたが、これ があったりなかったりするプロジェクトが ある。 • ちゃんと調べたらRailsの.rspecのオプショ ンで指定できるということを知る • spec_helperとrails_helperを使い分けて 活用することもこれを通して知る
49. 49 時間を変更するやりかた • TimeCopを使うみたいな話を聞いていたが Rails5.xでは ActiveSupport::Testing::TimeHelpers があるのでそれを使う • あまりコード例がないのでうっかり TimeCop使うところだった
50. 50 そして今
51. 51 Rspecを取り組んでいった結果 • 初めてガッツリ取り組んだのがAPIサーバ だったのでrequest specとmodelのspecは それなりに書けるようになる • 「Rspecを書かないと怖い」という感覚が 芽生え、馴染んできた • 実際にバグが発生したときも Rspecで再現、修正、確認というフローが できたので安心感があった。
52. 52 残された課題 • APIばかりだった反動としてfeature spec やsystem specに関してはまだ修練が足り ないので積極的に身に着けたい • WebMockに関してはまだ深いところを理 解できて使えてないのでしっかりと使いこ なせるようにしていきたい。
53. 53 まとめ
54. 54 まとめ • いきなりテストコード書く機会であったが まとめられた記事や電子書籍のおかげで基 礎固めはできた • 既存コードは右往左往する可能性があるの で、参考にするときは慎重に。よくわから なかったら右往左往する前に書き手に聞 く。 • プラグインや、定石でない使い方は わかりやすくするなどしてあげるとよいか も
55. ありがとうございました 55