ウノウラボ Unoh Labs: やってみようBDD on Sinatra
おはようございます。 うちだです。 みなさんテストコード書いてますか？ 私はテストと言われると、どうもやる気がおこりません。 そこでBDD！ 今回はBDD初心者の私が、やってみた過程を綴ります。ツッコミ大歓迎 BDDとは？ Behavior Driven Development 振舞駆動開発 テスト駆動開発ではテストのためにコードを書く 振舞駆動開発では振舞（仕様）のためにコードを書く 結果的にやる事はほぼ一緒 言い方でモチベーションがかなり変わる スペック！スペック！ 各言語のBDDフレームワーク Ruby RSpec .NET NSpec Java JBehave PHP PHPSpec 10ステップでやってみるBDD 1. インストール $ sudo gem install rspec 2. スペックを書く # spec/hello_spec.rb require 'hell
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
テストを書くときはコストベネフィットを考えろ - ひがやすを blog
InfoQにKent Beckの最新の提案がでてますね。Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案 でも、これは、Kent Beckが「ごく短期のプロジェクトではテストを省略しても良い」といってるわけではないと思うんですよ。キャッチーなタイトルをたまたまつけられてしまっただけで。 重要なポイントはここだと思います。 Maxを開発しているとき、テストを書くか否かという質問は、要するに、そのテストが単位時間当たりにより多くの有効な実験をするのに役立つかどうかでした。もし役に立つのであれば、私はテストを書きます。そうでなければ、不要だと判断します。私はMaxの収入を軌道に乗せるためのチャンスを最大化しようとしているのです。 つまり、「テストがかけた時間の割りに役に立つと思ったら書くし、そうでなければ書かない」ということだと思います。別に短期のプロジェクトでも、コス
UnitTestから RSpec on Rails に書き換えてみた (モデル編) - yuumi3のお仕事日記
次の仕事から 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の記事 : よくまとまっ
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、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 直
Ruby on Rails 2.3でテストを実行すると、undefined method `use_transactional_fixtures='というエラーになるときの対策 (山本隆の開発日誌)
« Ruby on Rails 2.3でDEPRECATION WARNING: protect_from_forgery only takes :only and :except options now. :digest and :secret have no effect. という警告が出るの対策 | メイン | ActiveRecordの設定をDRYにするDrySQLライブラリ » Ruby on Rails 2.3でテストを実行すると、undefined method `use_transactional_fixtures='というエラーになるときの対策 Ruby on Rails 2.3でテストを実行すると ./test/unit/../test_helper.rb:23: undefined method `use_transactional_fixtures=' for Te
るびま-Rails第６回
『るびま』は、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 直
assertの基本から - ザリガニが見ていた...。
前回の日記と順番は前後してしまったが、今まで適当に使っていたassertについても見直してみた。 assertのマニュアルページ Test::Unit - Rubyリファレンスマニュアル Rails Edge API documentation http://caboo.se/doc/classes/Test/Unit/Assertions.html http://caboo.se/doc/classes/ActionController/Assertions.html http://caboo.se/doc/classes/ActionController/Assertions/DomAssertions.html http://caboo.se/doc/classes/ActionController/Assertions/ModelAssertions.html http://cab
Route 477(2009-06-09)
■ [ruby] Rubyのテスト環境大戦争 おまいらは本当にテストが好きだな！というわけで、Rubyのテスト関係のライブラリを並べてみた。 テストフレームワーク Test::Unit Ruby標準添付のユニットテスト用フレームワーク。 RSpec DSLを使う、「BDD」という概念を流行らしたユニットテスト用フレームワーク。 Cucumber 自然言語を使って、ブラックボックステストを記述する。RSpecの「Stories」と呼ばれていた機能が独立した。 あとはShouldaとかbaconとかいろいろありますけども。 モック・スタブライブラリ モック＝あるオブジェクトに期待したメッセージが飛ぶかどうかテストするためのオブジェクト、 スタブ＝ネットワークが絡むとか、実際のオブジェクトが使えない場合に使う偽オブジェクト。 と思ってるんですけどどうなんですかね(more: モックとスタブの違い
MySQL::Sandbox - 日向夏特殊応援部隊
MySQL::Sandbox はお手軽に MySQL のサーバーを立ち上げるツールで、ちょっとしたテスト環境を構築するとかに非常に便利なプロダクトです。 とりあえずインストール $ sudo cpan -i MySQL::Sandboxでインストールしてから OS ごとの実行バイナリをダウンロードします。自分の手元の VM は CentOS 5.2 なので、mysql-5.0.82-linux-i686-glibc23.tar.gz をダウンロードしました。 まずは レシピ の最初にあるように make_sandbox してみます。 $ make_sandbox /path/to/mysql-5.0.82-linux-i686-glibc23.tar.gzそうすると /home/zigorou/sandboxes 以下にサンドボックスが出来てます。ついでに mysqld も立ち上がっていま
HTTP::Engineでテスト : As Sloth As Possible
そう言えばこないだのうどん屋のコードは一切テストを書かなかったけど、それはよろしく無い、まったくもって主義に反するし、RubyのときはちゃんとSpec書いたのにPerlのときは書かないだとかふざけてる、と思ったのでテストも書いてみることにした。 さてテストだけど、HTTP::Engineにはちゃんとテスト用のインターフェースが用意されている。あと、テストリクエストを生成するモジュールもある。なんだ、じゃあ話は簡単だ。 interface => { module => 'Test' } でengineを作る HTTP::Engine::Test::Requestでrequestを作る engineのrunメソッドにテストリクエストを投げてやる 返ってきたレスポンスをチェックする ってことですね、わかります。 まずは素直に書いてみる コード量少ないのではっつけちゃおう。Udon::AppにGE
Test::LatestPrereqs 0.01 - Charsbar::Note
管理しているモジュール／アプリケーションが増えてくると、なにかの理由（バグを見つけたとか新しい機能が追加されたとか）で依存モジュールのバージョンをあげようと思ったとき、「ほかにこのモジュールに依存しているものはなかったっけ？」と首をかしげることが増えてきます。そんなときのために簡単なテストを用意するのがこのモジュール。 インストールするとtest_prereqs_versionという非常にタイプしづらいコマンドがついてくるので、Makefile.PL/Build.PLがあるところで実行してやると、こんな感じでPREREQ_PMやらrequiresやらの情報をまるっと解析してバージョンチェックしてくれます。 C:\github\test-latestprereqs> test_prereqs_version 1..6 ok 1 - Test::More 0.47 is ok ok 2 - F
Apache::Test事始め - D-6 [相変わらず根無し]
Apache::Test事始め 年末前後からApache::Testで真面目にテストを書き始めている。 ところが全くドキュメントがないんだね。いや、あるんだけど、携帯の機能を使いたいだけなのにあの厚いマニュアル読むの？みたいな感じで。まぁというわけでとにかくざくざくっとドキュメント読んでテスト書いてたらようやくなんとなく分かってきた。この間ある程度他人にも説明できたので自信ついたしw Apache::Testはmod_perlハンドラをテストするときに使う。ディストリビューション等でmod_perlをテストしようと思うとApache自体を立ち上げたりなんだりしなければいけなくて「一体どうテストすればいいんじゃ？！」となりがちだが、Apache::Testを使うと、テスト用httpd.confの生成テスト用のapacheの起動／停止mod_perlハンドラ上で動かしたTest::More等の
第4回 Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介 | gihyo.jp
Happy Testing Perl 第4回Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介 モバイルファクトリーの小林です。今回は今までに紹介しきれなかったPerlのTestingモジュールで良く利用されるものをいくつか紹介したいと思います。 Test::Perl::Critic このモジュールはテスト対象のコードがPBPに準拠しているかどうかをテストしてくれるモジュールです。 PBPとはDamian Conway氏の提唱するPerl Best PracticesというPerlのコードを書く際のスタイルです。 http://www.oreilly.co.jp/books/4873113008/ Perl Best Practicesについての詳細
Test::UseAllModules 0.11 - Charsbar::Note
ユニットテストを多用するようになって、t/lib配下のモジュールそのもののエラーでテストが止まることが増えてきたので、Test::UseAllModulesを拡張してテストしたいディレクトリを追加できるようにしました。使い方はこんな感じ。 use strict; use warnings; use Test::UseAllModules under => qw(lib t/lib); all_uses_ok();「under => 」の部分は省略可。libはデフォルトでチェックするので入れなくてもいいです。 例によってMANIFESTに入っているモジュールしかチェックしませんので、私はなにかモジュールを追加するたびにModule::Newのmodule_new manifestコマンドでMANIFESTを更新しています。
ダミーデータを自動生成したい！プロジェクト - taiyoh独言
先日のエントリから更に掘り下げて、ダミーデータをある程度自動的に生成できれば、手間がもっと減るのではないかと考えた。 結果→GitHub - taiyoh/test-dummygenerator: for people who are lazy not to want to create many many test data... ハッシュリファレンスベースで、ある程度値の方向性がついている感じです。 #!/usr/bin/env perl use strict; use warnings; use Test::DummyGenerator; use YAML qw/Dump/; my $dummy = Test::DummyGenerator->new( schema => YAML::Load(do { local $/; <DATA> }) ); my $data = $dummy
Fixture系モジュールはコールバックで値を入れられる方がいい - taiyoh独言
例えば日付に絡むテストをしたい時、ダミーデータとしてハードコードしてしまうと、後々、データが古いというだけでテストがコケるという可能性が出てくる。 まあ、可能性というか、実際今僕のところで起きたんだけどさ。 もうちょっと具体例を挙げると、週間ランキングのロジックをテストをしたいとかいうとき、ギリギリ3,4日後くらいまではなんとかなっても、もし１ヶ月先に何らかの事情でそのテストを回したいとき、そんなところで落ちてたら、無駄に原因究明の時間を使う事になる。 ということで、DBIx::MoCo::Fixtureのload_fixtureをちょっと弄る。 { package DBIx::MoCo::Fixture; use Data::Visitor::Callback; our $Substitutions = {}; sub append_substitutions { my ( $key,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラミング言語 Ruby リファレンスマニュアル
http://www.func09.com/wordpress/archives/532
Unit Test Your Database
