Kanazawa.rb meetup #72 に参加しました #kzrb #ふくもく会

kzrb.doorkeeper.jp

fukumoku.connpass.com

今回はKanazawa.rb 6周年記念回ということで恒例のLT大会が行われました。また、同時刻にふくもく会も開催されており拠点をzoomで繋いで発表し合うというスタイルでした。

6周年記念のカラビナ。普段使いにも良さそう。(雑に接続した模様です...)

話したこと

Webアプリケーションを開発するに当たって意識していることを雑に発表しました。チーム内で言われていることだったり、meetupで聞いたことだったり影響を受けているものは結構あります。

初めの2つに関しては前々から言われていることではありますが、チーム内でフォーカスが当たることが多かったので採り上げてみました。そういえばリーダブルコードでそんな話あったなと思い調べてみたらやっぱり書いてありました。テストコードの話については、異常系のテストケースは完全になることはなくて漏れることは多々あるので生じたバグに対して積み上げていくのがいいんじゃないかなと最近思ってます。発表では触れてませんがProperty Based Testingについても調べてみたいなと思ってます。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
出版社/メーカー: オライリージャパン
発売日: 2012/06/23
メディア: 単行本（ソフトカバー）
購入: 68人クリック: 1,802回
この商品を含むブログ (140件) を見る

テスト童貞としては、大事なのはわかるけど、どこから手をつけていいのかよくわかってない & カバレッジが高すぎてもよくないとかも聞くし #kzrb
— |дﾟ)ﾉ ⌒ ɐʍɐʞɐuıɯ (@yu_kgr) 2018年8月18日

拾いきれなかった質問というかツイートがあったので補足すると、私は『The RSpec Book』を読んでこんな感じでテスト書いてけばいいのかーというのをきっかけにした感じです。実際はBDDのお話がメインにはなってくるのですが。あとは『Everyday Rails - RSpecによるRailsテスト入門』という電子書籍が出ていて、こちらは最新の環境に追随していてかつ実践的な内容なのでRailsを使っている|使おうとしているならばオススメです。実践の話で言うと、自分の実装部分からテストを書いてみるという手法があって、最初は最低限のもの(自分の触る単一のメソッドに対して等)だけ書いてって少しづつサイクルを回していくということは過去に経験しました。そのときは、プロジェクト自体にほとんどテストコードが無かったのでちょうど勉強してたし書いてみるかーと手を付けた流れでした。

カバレッジに関しては最初から数字を目的にするのは相応しくないなーと思ってまして、設計の元になる、ドキュメントになるというのが本質的にあって結果としてこのくらいカバーしてますよと。それと並行して、品質を担保するのにユニットテストをもっとやるのか、E2Eテストをやるのか、方法はいろいろあると思いますけどもどのようにしていくかというのを決めて、ユニットテストのカバレッジはこれくらいあればいいよねと言う話になるのかなと思っています。あまりうまくまとまってませんが、こんな感じです。