Email API/SMTPRESTful API and SMTP for reliable email sending
Railsエンジニアになってから1年半くらいが経ち、社内のRailsのプロジェクトを全部で5つくらい触って、今やってるAbilie*1でようやく人並みにテストを書いてる気がしてきたので、現時点でやってるテストの方法をまとめておく。 テストのルール的なの rspecでは必ずモデルのテストは書くようにしてる。ヘルパーも大体書いてるけど、コントローラやルーティングのテストはあまり書いてない。 というのも、コントローラーのコードを極力短くしてモデルを太らせているのでコントローラのテストはあんまり意味が無い気がしていて、その代わりにCapybaraでテストを書いておけば十分なんじゃないかなと思ってきたから。Capybaraは書いてるので、そういう意味では書いてるとも言える。 社内の管理者だけが使える管理画面も作ってるけど、そっちはテストあんまり書いてない。ここは動かなくなっても一般ユーザーには影響が
2011-03-12 近況 無事です. はいいとして, 先週 Shibuya.js で話してきました (スライド). 空気をよまず JS と無関係の話をしてしまいやや申しわけなかったけれども, WebKit の様々な幻想をぶちこわす開発の様子を知ってもらうことには個人的な使命感を感じておりつまりこれはちょっとした十字軍なのです. JS のテストってなんでむずかしいの? 地震さわぎで自宅警備中の人も多いだろうから, お互いの気晴らしをかねてだらだら書きたい. JavaScript のテストについてぐぐったりついったを読んだりしていると, JavaScript でテストを書くのは大変だとか難しくてやってないという話が多くて不思議におもった. 私は JavaScript を使ってウェブアプリを作る仕事をしたことがなく, いまいち難しさがピンとこない. 趣味でさわっている範囲だと普通に書ける. な
どうも皆さんこんにちは、GW返上で頑張る babie でございます。日中にキャッキャウフフ行楽してる奴は殺人光線を浴びて死ぬ。 Rails のインテグレーションテストで一般的となった Capybara ですが、JavaScript のテストには選択肢が色々あります。envjs, selenium, akephalos, celerity, culerity などなどです。迷いますねー。 ですが、当方、Ruby 1.9.2 p136 on VPS の関係のため、 envjs ―― 依存してる johnson が Ruby 1.9 系列ではコンパイルできないので× selenium ―― X ごっそり入れるのイヤなので× akephalos ―― 依存してる HTMLUnit が jQuery 1.2 までしか対応してないので× celerity ―― JRuby 専用なので× culerit
2011/07/07追記 実はこの記事の内容よりも以下のGuardを前提にした構築がおすすめ。 Rails3+RSpec2+Spork+Guard(guard-rspec,guard-cucumber)で最速のBDD(振舞駆動開発)環境を作る | Curiosity Drives Me Guard便利すぎです。 久々にRailsでできる仕事が来たので久々に環境構築。 記事の一番最後に挙げた参考の渡り歩きつつ設定した。 Rubyのバージョンは1.9.2。Railsは3.0.5。 プロジェクトの作成 $ rails new -T hoge RSpecを使うのでUnitTestはいらないということで。 Gemfile 必要なものをBundlerでさくっと入れる。 group :development, :test do gem 'spork', '~> 0.9.0.rc' gem 'rspec-
WEB+DB PRESS vol.61の「Rails3テスト最前線」という記事がかなり良かったので、注釈を交えて紹介したいと思います。 何が良かったのか? 自分はRails2系でTest::Unitを実践していました。AutoTestとYAMLによるデータ投入でおおむね満足していましたが、次のポイントが気になっていました。 YAMLによるデータ投入は重複が多いのでコピペでデータを作成していた。 Test::Unitはログイン処理など共通の処理をくくり出すのが難しかった。 Viewのテストの方法が分からなかった。 しかしこの記事で気になる点がスパッと解消されました。私と同じような人はこの雑誌の記事が役に立つと思います。 ちなみに私はMacのSnow Leopard上でRuby1.9.2を使ってこの記事の内容を試しました。1.8.7を使う前提で書かれている箇所もあるので注意してください。(後で
はじめに Web APIを使って様々なサービスと連携するというアーキテクチャはすっかり定着した感があります。みなさんも、Web APIを使ってデータをやりとりするアプリケーションを書く機会も増えているのではないでしょうか。 Web APIを使うアプリケーションの開発では、テストやデバッグをする際のAPIアクセスが悩みどころとなります。本物のサーバを使ったのではテストデータの初期化などに手間がかかりますし、逆にHTTPアクセス自体をスタブやモックを使って間接化してしまうとそれが本当に有効なテストなのか不安が残ってしまいます。 筆者も、仕事やプライベートでのコーディングでこのような悩みに何度も遭遇しました。これらを解決するために開発したのがwwです(wwと書いて'double-web'と読みます)。 ダミーWebサーバ作成ライブラリww(Double Web) wwは、Webサービスの簡単
めも FGはdefineの仮引数周りが無駄 (blueprintで改善) FGはinstanceをフラットに管理しすぎ FGのsequence(next)はイケてる FGはAR前提 Machinistは定義がイケてるが、名前がダサイ(make_unsaved) Machinistはメソッド名が衝突しそう(makeはアカン) Machinistはinstanceをクラス毎に分類できるが、Shamレベルまで落ちるとフラットになる片手落ち感 Daddyの使えなさは異常 FGの継承はどうやるの?(-> :parent) FG.blueprint は :parent を理解してくれない 試行錯誤 Factory.sequence :login do |i| "login#{i}" end Factory.define(:user) do |user| user.login {Factory.next
何を今更、なことかもしれないないのだけど、もしかしたらこれを知ることでTDD(Test-driven development)をやることのハードルが一気に下がる人がいるかな、と思ってメモ。 特に、ある程度プログラマとして経験があるけど、どうもTDDは慣れないという人向き。 “TDDとは、TDD以前に脳内や機上でやっていたことをコードに落とすことに過ぎない” このことが解ってから、TDDをするのが一気に苦痛ではなくなり、むしろ楽しくなった。 TDDでなくても、コーディングをするとき、temporaryなテストコードを書いたり、目視でのチェックはしたりするものだろう。たとえば、一時的に変数の値をハードコードして挙動を変えてみて、それを目視で確認したり、printデバッグとかもその一部だ。 つまり、このtemporaryなコードや目視している部分をpermanentにするのがTDDで書くテストコ
フィクスチャはメンテナンスしづらい 書籍The Rails Wayの中には「皆フィクスチャが嫌い」という項目があります(次の項目は「フィクスチャはそれほど悪くない」ですが)。 フィクスチャが嫌われる最大の原因は「メンテナンスが難しい」という事でしょう。 中間テーブルを必要とする多対多の関連をフィクスチャにしようと思ってうんざりした経験は誰にもでもあると思います。 Fixtureのhas_manyでこんな書き方したい https://func09.com/wordpress/archives/369 フィクスチャの代わりにFactoryGirlを使ってみる Factory GirlはRailsのテストにおいてfixtureの代替となるツールです。 つまりテスト時のモデルデータを用意するための仕組みです。 Factory Girlはフィクスチャと違い、Rubyのスクリプトで直接データを定義して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く