by shigemk2

当面は技術的なことしか書かない

Rails勉強会@東京 第79回 TDD OOP DCIについて #railstokyo

ダラダラメモ。

Guard
herokuのバグによりgemfile.lockが読みこまれないことがある
RSpecはGuardよりも遅いしイライラする

Sporkとかを利用してRSpecの起動を速くする
zeus 神なのにゾンビ

Rails 3 でSpork + Guardで快速自動TDD - テクノロジーと広義のデザイン!

結局SSDにしたほうが早いんじゃないだろうか

spe_cuke

spe_cuke (rspecとcucumberを同じコマンドオプションで指定できるようにする)

$ gem install spe_cuke

moro/spe_cuke · GitHub

vimrspecかcucumberをひゅっと実行できるようにする

function! s:SetupSpeCuke()
  command! RunTestFile exe '!sc ' . expand('%:p')
  command! RunTestCase exe '!sc --line ' . line('.') . ' ' . expand('%:p')

  nnoremap -tf :RunTestFile<CR>
  nnoremap -tc :RunTestCase<CR>
endfunction

au BufRead,BufNewFile *_spec.rb,*.feature call s:SetupSpeCuke()

ただ、名前がダサすぎるので、scとかに改名したらいいんじゃないのか?
また、デバイス調べる時間のほうがコードを書く時間より長くなってしまっておる。

レガシーコード改善

テキストのリクエストはテキストのリクエストで返ってくる
DOMで現れる部分であれば、JSですらもcucumberでカバーできる

ただ、javascirptでcanvasで描画したやつは自動化のしようがありません。
所謂webアプリケーションのテキスト部分は自動化テスト可能である。

jenkinsが死ぬほど遅い

(15分かかる)
CIをうまく回している人っている?
C社は金で解決したらしいけど。

安いnodeを複数回かけてspecとcucumerを1台ずつ分ける
(小賢しい技術を駆使するくらいなら、普通にお金をかけてサーバーを増やしたほうがよい)
(でも企業の体力と要相談です)

specでviewのテストやってる?

コンテンツの中身にたいしてテストしているわけではなく、
htmlが壊れていないかとか、静的メッセージがきちんと表示されているかを確認する
featureに書くと重たくなるから。

controller spec

テンプレートのサーチパス
エンドポイントが分からない

controllerのspecを作ればhtmlとかjsonとかを吐きだす

そのままドキュメント化しておけばAPIドキュメントの代わりになるし、
ドキュメントを書くくらいならcontroller specをかいたほうがいい

model spec

controller specを優先する?(それはない)
どこまで書くか、というよりどこに書くかのほうが重要です
end2endをやると遅くてたまらない

modelに書くテストは開発者目線のテストであって、システムそのものを担保しているわけではない。
ロジックのテストを最初にやるべき

どこまで書くのか

プライベートメソッドのテストも書く人もいる
(ちょっとヤバそうだったら書く or プライベートも全部書く)

分割して外に出したほうが効率はよい。

active recordを継承しているクラスとそうでないものが半々くらい
クラスが多いのはよい。小さいクラス

クラスを命名するのがしんどくないか?
→ネーミングがプログラマの仕事の半分近くを占めてます

ship quality ruby code
Code Climate. Hosted static analysis for Ruby and JavaScript source code.

メソッドのネーミングとかソースコードとかを自動的に判断して、ランクづけしてくれる(無料だけど有料オプションもあり)
モジュール切り出し、機能単位でタグづけとかをやると本体のスコアが上がっていく

物理的に短くするのも重要じゃないだろうか
#398 Service Objects (pro) - RailsCasts

実践テスト駆動開発入門

日本語訳

(サンプルがガチすぎる)

原著

(サンプルコードがハードコアすぎる)

httpリクエストを作る必要がない
モデルからよせたほうがレイアウトとしては楽

紙面上でjavaのコードを読むのはキツイ。

DCI

そもそも話すの?
rubyのイベントに出たのにjavaの話するのか

そもそもDCIって何?
DCI and the application builds our mental models // Speaker Deck

MVC以外の切り口

Data
Context
Interaction

(例によって)口座管理のお話が出てきます
「預け入れと引き出しは振舞いが違うよね」って話

「客と開発者の言葉の定義を統一していこう」という話なのか?

イマイチ「コレダ!!」って話がない。

オブジェクト指向つって結局クラス作ってるだけじゃん!

DCI and the application builds our mental models | Sapporo RubyKaigi 2012 (札幌Ruby会議2012)

コントローラーを少なくするのはいいが、
モデルを肥大化さすのはよくない

若干限界が見えはじめているMVCにたいし、一石を投じるDCI

DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism