RubyKaigi 2011の二日目が終わりました。来場者の皆さん、スタッフの皆さん、誠にありがとうございます。 いろいろ忙しかったり、緊張したりもしたけれど、とても楽しい時間を過ごせています。三連休完全外出を許容してくれた妻子にもありがとう。 さて、今日は発表枠をいただいて、RSpecでテストを書きながらRailsアプリを開発する話をしました。 Test Context Arrangement Recipebook View more presentations from Kyosuke MOROHASHI 講演中にも申したとおり、最初のRubyKaigiが行われた2006年(の会議終了ちょっとあと)からいままでの5年間ほぼ毎日、RSpecとRailsを使ってきました。今日はそこで見いだしつつある【独自研究】を話させていただきました。講演終了後から懇親会で声をかけていただいた方々には好評
本の紹介第2弾。少し前、Twitter上でTDD/BDDについて盛り上がっていたので、この本を紹介してみたくなった。 「The Rspec Book: Behaviour Driven Development With Rspec, Cucumber, and Friends」という本。 この本は、RspecとCucumberを使い、どう考え、どうシステムを作っていくか、というをチュートリアルを交えながら紹介する構成になっている。 ただUnit Testを紹介するだけではなく、Unit TestツールであるRspecに、BDDツールであるCucumberを組み合わせて使うことで、Unit Testでカバーできない部分をCucumberで補い開発をする、というところがこの本の肝になっている。 この本を読み、実践することで、Unit Test*だけ*を書いてシステムを作っているときのモヤモヤ感
BDDについて自分なりにまとめてみた Published on 2011-07-02 Updated on 2011-07-02 BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振
前回の続き。 plugin機構とか Riddle.jsにはplugin機構があります、と書くとなんだかカッコよさげに聞こえるが、それは結局外部にエクスポートされているシンボルのうち2つ(rとr.fn)に関数を生やすとpluginっぽいことが出来ますよ、というだけの話にすぎない。r.fnは、セレクタで返ってくる結果セットが継承する元の雛形となっているオブジェクトで、jQuery.fnみたいなもんである。(今これを書いてて思ったけど、Property Descriptorsを使って外部pluginから既存APIの書き換えなどを防ぐ、というのはアリかもしれない。おそらく、そこまでしなくてもいい類のものだけど…) coreを出来る限り小さく保ちたいという理由から、常に必要ではない要素 or 実験的な要素はpluginと付属させることにした。Zeptoと同じ方法を採用しているわけだが、Zeptoとの
こんにちは、寝過ごして長野まで行きそうになったソーシャルクライアント開発のtakimoこと瀧本です。 先週弊社数名がアメリカで行われていたVelocity 2011 - O'Reilly Conferencesに参加しました。 そこではモバイル端末のテストやパフォーマンスについての講演やLTがあったようです。 自分もお土産話を色々聞きたいので詳しくは誰かが書いてくれるはず...です。 その中で気になったプロダクトがあったので紹介したいと思います。 weinre - Web Inspector Remote weinreはFirebug(Firefox)やWebKitのWebInspectorのようなデバッグ機能をリモートで提供してくれるプロダクトです。 iPhoneやAndroid(2.1以上)には一応コンソール機能のようなものがありますが 基本的には出力だけ ソフトキーボードでデバッグ用
Perlではメモリリーク検出ツールがいくつか開発されているので、top(1)の結果を眺めるよりそういうツールを使うほうが楽である。 さて、メモリリークが発生しているとき、その可能性としてはだいたい以下の4つが挙げられる。 Perlレベルでの循環参照 グローバル変数に値をどんどん足しているとき*1 XSレベルでリファレンスカウントの管理ミス XSレベルでmalloc()したメモリの管理ミス この1-3についてはすべてPerlインタプリタ内の出来事であり、Test::LeakTraceを使って検出できる。4を検出するのは難しいが、Test::Valgrindが役に立つ。 Test::LeakTraceのSYNOPSISは歴史的経緯によりごちゃごちゃしているが、テストで使うべき関数はno_leaks_ok()とleaks_cmp_ok()だけである。 たとえば、以下のようにして使う*2。 #!p
一度作成すればすばやくテスト可能である。 その後はテストコードを標本とすることでバグ訂正が容易となる。 テストコードを見れば仕様が一目瞭然となる。 誰でも同じテストを行えるようになる。 独自のテストコードによるテスト作成の手間を省ける。 仕様変更ごとにテストコードを作り直さなければならない。 EclipseなどのIDEを使うことで、テストコードの再作成によって生じる手間を軽減することもできる。 エクストリーム・プログラミング(XP)などのテスト駆動開発の開発形態の場合、問題が解消される場合がある。なぜなら、テスト駆動開発では、テストコード自体が仕様であるという考え方に立つからである。 テストコードの作成に時間がかかる。 EclipseなどのIDEを使うことでテストコードの作成を高速化することもできる。 「テストは機能テストであり、内部ロジックの確認ではない」という考え方に立つと問題が解消さ
このウェブサイトは販売用です! twiwt.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、twiwt.orgが全てとなります。あなたがお探しの内容が見つかることを願っています!
■ [rails] Railsのテストを高速化するやつ ちょっと調べた。導入はわりと簡単なので試してみると良いです。 spork Railsをロード済みのテストサーバを立てることによって、テストの起動時間を短縮する。 https://github.com/timcharper/spork Twiwt:Blog / jugyo : spork でサクサク RSpec on Rails3 Rails 3対応。Rails 2の場合はspork 0.8.xを試せと書いてある。 テストフレームワークはRSpec、Cucumberに対応。Test::Unitを使う場合は https://github.com/timcharper/spork-testunit を入れる(ただし1.9未対応…)。 parallel_tests テストを複数のプロセスで実行することによって、テストの実行時間を短縮する。 (
WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです! 次の形式で書いています。 WEBサイト名、資料名:発表者(敬称略):URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
本日大江戸*1で行われた大江戸Ruby会議01で、高速なテストサイクルを回すにはという内容で発表してきました。 大江戸Ruby会議01 高速なテストサイクルを回すには View more presentations from hotchpotch テストを速くするには二パターンあり、一つは単体実行時の速度・フィードバックの高速化、もう一つはすべてのテスト実行時の高速化があると思っていて、それらについての話です。ぎゅっとまとめると、前半の単体実行時の速度・フィードバック高速化には spork / prefetch-rspec / autotest / watchr を使おうという話と、後半は REE / parallel_tests による高速化・並列実行、remote spec によるリモートマシンでの分散テストについての話です。 特にオレオレプロジェクトの prefetch-rspec
テストの無いプログラムは、クリープの無いコーヒー・・・。いや、趣向の問題ではない、おっかなくて使う気になれない。 ここではテストを行う際に、実施条件下で変わる情報、外部リソースを扱う場合などに有効な Stub と Mock の簡単な使い方をメモしておく。 Ruby では、Stub と Mock を扱う場合の選択肢はいろいろあり、また、いろいろ熱すぎて何を選択していいのかわからなくなる。。 他にも RSpec、Mocha などあるが、ここでは、FlexMock を使うことを前提とする。 Flex Mock RubyGems でインストールできるので、インストールしておく。 $ sudo gem install flexmock Mockfight! FlexMock vs. Mocha のスライドなどは、使い方のサンプルとしても参考になる。 Table of Contents Open Ta
Autotest, guard-spork, and ruby-debug Quick link to a sample app. Autotestはテスト駆動開発において欠かせないツールです。しかし、特にRuby 1.9ではRspecの起動の遅く、イライラしている人も多いでしょう。 Rspecの起動を早くするツールにSporkがありますが、以下のような問題があります: 製品コードを更新してもリロードしてくれない(ぇ ruby-debugが使えない このエントリではこれらの問題を解決していきます。目指すのは次のような環境です: appの下はもちろん、configの下を更新した場合もリロードしてテストしてくれる 製品コードでもテストコードでも、debuggerと書いたらruby-debugが使える Spork まずはベースの環境から作りましょう。なお、ここで使うのはMac上のRails 3.
次の仕事から RSpec を使ってみようかかと思い RSpec on Railsを使ってみました。まずは、勉強にと UnitTest を RSpec on Rails に書き換えてみた。 ドキュメント・参考資料 RSpec-1.1.11: Overview : RSpec ホームページ、英語ですが例が多く実際にSpecを書くのにとても役に立ちます。 Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編) : 日本語の解説、長いけど一読、二読しよう! Rubyist Magazine - スはスペックのス 【第 2 回】 RSpec on Rails (コントローラとビュー編) : 日本語の解説、長いけど一読、二読しよう! WEB+DB PRESS Vol.45 YugiさんのRSpecの記事 : よくまとまっ
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
本日行われた Shibuya.js の発表資料をアップしました。 さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料 View more presentations from hotchpotch JS のテスティングフレームワークのおおざっぱな説明や JavaScript テストにおける問題、それについての解決方法の一つ、CUI でのテスト、Envjs、エンドツーエンドテストにおける JS / Ajax のテスト、終わりにちらっと Phantomjs の話があります。 スライドの最後にあるように、やはりまだコレだ!という JS のテスティングフレームワークは存在しなく、今後 JS のテストは『僕らが書きたいテスト』をどれだけ簡単に書ける・書く手法が確立されるかによって流行廃りは決まってくるんじゃないかなぁ、と思ってます。そのうちの一つがスライ
さっき nekokak さんと xaicron さんにそそのかされて Test::Mock::Guard ってモジュールを書いてみました。 そもそも Perl には Test::MockObject と言う汎用の Mock モジュールがあるんですけど、あれこれ余計な機能がたくさんついてたり Mock 化すると多分元に戻せないと言うのがあってもっとシンプルな奴がほしいなと思って作ってみた次第です。SYSNOPSIS のコピペですけど、 use Test::More; use Test::Mock::Guard qw(mock_guard); package Some::Class; sub new { bless {} => shift } sub foo { "foo" } sub bar { 1; } package main; { ### このスコープでは Mock 化されてる my
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか? グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く