-
Notifications
You must be signed in to change notification settings - Fork 1
2015.05.16 Test Code Discussion for Rubyists
Junichi Ito edited this page May 19, 2015
·
24 revisions
- 日時: 2015/5/16 (土) 12:00-18:00
- 場所: Nilquebe
- 告知: Rubyistのためのテストコード相談会 ~テストの書き方に悩んでいませんか?~
- 参加者一覧: http://rubyist.co/nnect/events/3
参加レポートを書く際に利用してください。
-
event.users += users
のような書き方ができること - FactoryGirlの
create_list
(すっかり存在を忘れてた) - 他にもあった気がするけど思い出せない。。
- 開催前は「大丈夫かな~」って毎回不安になるんですが、今回も予想以上にマニアックで熱いディスカッションが繰り広げられました。いやあ、楽しかった。
- Rubyのテストコードに特化した勉強会というのは全国的にも珍しい気がするので、結構貴重な勉強会になったんじゃないかと思います。
- 懇親会もみなさんの生い立ちやこれまでのキャリアがいろいろ聞けて面白かったです!
- 初心者さんは若干置いてけぼりにしてしまったのがちょっと申し訳なかったです ><
- 寺田さんに始終書記をやってもらいましたが、途中で誰かに変わった方が良かったかもしれません。。(寺田さん、どうもお疲れ様でした!)
- Rubyist Connect、実際に勉強会で使うと機能追加したいところがいろいろ出てきますね。
- ニルキューブさん、いつもお世話になってます。広くてきれいで毎回とても快適に使わせてもらっております。(西脇から電車であと30分早く着けたらいうことなしなんですが・・・!!)
- RSpec初心者の方は僕がQiitaに書いたRSpecの入門の記事をご覧ください!
- ライブコーディングで書いたテストコード
- minitest:フラットな関係のテストをやる時に便利
- rspec等価な同じメソッドがあるのは、自然な英文を作るため。
- FactoryGirlの存在と役割
- Rspecとminitestの役割の違い そんな複雑ではないテストを実施する場合は、シンプルなminitestを使い、 もっと複雑なことをやりたい場合はRspecを使ったらよいという理解。
- テストに対する考え方などを聞けたのは面白かったです
- コードの品質の担保など、現場で働かれている人の意見はすごい刺激になりました
- ちょっと自分の事前知識が足りなかったので、内容がついていけないところが結構ありました。
- 実際にテストコードをみんなで書いてみても面白かったかもしれません。
- 個人的にすごい勉強になることばかりで、本当にありがとうございました。
- あと個人的に、CIでソフトウエアのコードチェックをしてくれるツールを知れたことも 良かったです。このあたりの情報もありがとうございました。。 https://codeclimate.com/
- 最初のコードを捨てて、新たにプロダクトコードを書かれるという考えも真似したいなと思っています。
- 次回の勉強会までには、今日の勉強会で仰られていた内容がだいたい理解できるように進歩したいなと思っています。
- テストコードも優先度を決めて、重要なところだけ書くスタイルもありということ
- テストコードを書いたことの無い人間でも、参加させて頂いて有難いと思った。
- これから、テストコードを書いていく際にどーゆーところで悩んだり、ハマったりというところが聞けて良かった。
- ひとまず、Rails のテストフレームワークは rspec が一番手堅そうだと感じた。
- ほとんど、話題について行けなかったので Rubyist Connect を題材にテストコードを書きたい
- 今後、勉強会の開催日程が2、3ヶ月に1回のペースになるみたいなので 個人プロジェクト(Rubyist Connect)を頑張る
- 参加人数少なめの Rubyist Connect ハッカソンを開催して Issues の整理や機能開発、Bug Fix とかやれたら楽しそう #利用規約も作らないと、、、
- (ブログ等のURLがあれば書く)
- なし
印象に残ったもの
- 作りながら仕様を決めるような場合はテストコードは後から書いている
- プロトタイプができたら(仕様が決まったら)、そこからTDDでプロダクトを作り直すというのも良い(全て捨てなくてもメソッド単位で作り直すなど)
- 条件が複雑になるようなテストケースを考えるときは、ディシジョンテーブルとか直交表を活用すると良い
- rspec-parameterizedの存在(条件と結果がテーブルで書けるなら、そのテーブルを使ってテストする)
- 検索条件を作る場合に一旦中間表現に変換し、その変換のテストと、実際の検索を分けてテストするケースもある
- テストコードを書く判断として、重要な部分、手でやるには手間がかかる部分という一つの判断
- テストコードはDRYにこだわりすぎなくて良い(プロダクトコードはDRYを目指す)
- テストケースのコメントについて、英語化が難しい表現などは日本語で書いている(テストにコストをかけすぎないようにする)
- モックやスタブは、本当に必要なときだけ使う(外部サービスと連携する場合、意図的にエラーを発生させる場合、期待する結果を得るのにいくつもの設定や条件が必要な場合など)
- Nilquebeさんの環境は勉強会に集中できます(許容人数も多いので多くの人の意見も聞けます)
- 思っていた以上に白熱しました!
- Rubyist.connectが勉強会で大活躍!(普段はアクセスしていないですが、勉強会での利用価値は高いと感じます!)
- 自分が知りたいことを聞きすぎていたのかも(発言者に偏りがあったかなと)
- 思った以上に濃い内容だったので、これからテストについて勉強したいって人には重すぎたかもと心配(テストコードがなぜ必要なのかといった内容から共有しても良かったかも)
- 初参加の人と話をしていなかった(席替え、休憩兼ねて話をする機会を作る?)->毎回思っている気がするがうまく次に活かせていない、、、
- 寺田さんのメモが助かりました!(ポイントになりそうな発言などは、寺田さんに記録できたかの確認を取った方が良かったかな)
- GoogleDocsだけでなく、タイムラインでメモや感想が残せると良いかも(皆んなで議事録を残せるし)
- 伊藤さんのライブコーディングを見るとテスト楽しい!って感じました。(ハンズオンセミナーやってもらえると、特にテストコード勉強したい人にとってはありがたいかも)
- テストコードを書く優先度についてみんさんのご意見をお聞きできて参考になった。
- カバレッジについてrubymineで把握出来るのは楽しそう。
- TDDについて再考しようかと思いました。
- 書記を途中でかわればよかったなと…お一人にお任せしてしまって申し訳なかった。
- 伊藤さんがライブコーディングでテストコードを書くとさくさく進むので楽しそうでした。
- 中間表現でテストする
- Rake タスクのテストもかく
- ライブコーディングもみれて、テストかくときの考え方やかきかたなどとても参考になりました。
- テストかくモチベーションが高まった
-
rspec-parameterized
(https://github.com/tomykaira/rspec-parameterized) が結構使えそう - 伊藤さんもテストケースのコメントを日本語で書くことがある!(無理して英語を使わなくてもいい)
- 最後のライブコーディングが参考になりました。
- 寺田さんの議事録、本当に助かりました。ありがとうございます 🙇
- Nilquebeさん、いつも美しい会場をありがとうございます 😄
- (とてもできる人・そうでない人、どちらに合わせるか難しいところだと思いますが…)内容がハードで、自分含め初心者の人が置いて行かれがちだったこと 😦
- ペアプロ等、実際に手を動かしてみる時間があればやってみたかったです。
- 次もしあれば、もっと勉強して経験を積んでから参加させてもらおうと思いました。
- ライブラリなどのテストではMiniTestを選択肢に入れて考えてみてもいいかもと思った
- MiniTest::Specの存在。。
- たくさんのCIサービス、アプリケーション
- モックの使いどころや、テストのグループ化の加減、カバレッジに対する考えなど、もやもやしながらテスト書いていたのようなことが 今回のような相談会があったからこそ、スッキリできた!
- 条件の組み合わせが複雑な場合などのテストをどうするかという話題で、紹介された考え方やテクニックは活用したいと思った
- とても相談しやすい相談会だったので、「自分にもっと相談したいことがあれば!」と思いました。
- 今回のような相談会の時は議事録係はとっても勉強になるのでオススメです(確信犯的立候補)。
- テストツライヨーメンドーダヨーと最近思いかけていましたが、自分でハードルをあげすぎずにコツコツ書いていこうと心機一転しました!
- rakeタスク用のテストgemとして willnet/rake_shared_context がある
- テスト実行時にDatabaseCleanerでマスタデータなどテスト実行時に一度だけ登録してすべてのテストで使いまわす方法があるのを知らなかった。というのと調べてなもなかった。
- デシジョンテーブルでテストケースを細分化して仕様を洗い出すという点がとても有用な情報だった。直近の業務で複雑な条件分岐があるのでそこで利用しようと思った。
組み合わせテストを開発現場で使いこなすには?――考え方のヒントと5つのコツ (1/3) - @IT - 時おり見せる伊藤さんのライブコーディングでFeatureSpec当たりのテストコードがとても参考になった。
save_and_open_page
current_path
など。
- 勉強会に関してではないですが、テストコードをもっと書いて、テストコード力を上げたい。
- 僕の発言した質問はふわっとした質問をしていたのが多かったので、回答するのも難しかったのかなという印象だった。こういう相談会はもっとサンプルコードを出していきたい。
- rubyist-connectになんかコントリビュートしたいと思った。
↓以下テンプレ(コピーして使って下さい)
- 何か書く
- 何か書く
- 何か書く
- (思ったことを何でも)
- (ブログ等のURLがあれば書く)