RSpecでGrowlなテスト環境♪ - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年12月29日08:34 Ruby RSpecでGrowlなテスト環境♪ mac で Growl な環境で、テスト環境を構築してみます。利用するライブラリは以前も紹介しましたが、rspec + rspec-rails + autotest(ZenTest) です。で、.autotest をこのように設定しました。これでテストの度にその結果を Growl で通知してくれるようになります。 require 'autotest/redgreen' #require 'autotest/growl' IMG_OK = '~/.autotest_icons/rails_ok.png' # 成功時の画像 IMG_NG = '~/.autotest_icons/rails_fail.png' # 失敗時の画像 IMG_PD = '~/.autotest_icons/syatyou.jpg' #
Rails3でTDD環境を整えたメモ - ひげろぐ
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-
レスポンシブデザインのテストツールx4 – creamu
Device-Agnostic Approach To Responsive Web Designという記事で、レスポンシブデザインのテストツールが4つ紹介されています。 Responsive Design Testing URLを入れると4つの画面でプレビューできるツール Responsive.is URLを入力すると、デバイスごとのアイコンクリックで表示を切り替えられる Responsinator URLを入力すると、デバイスごとの見え方をざっと見渡すことができるツール BriCSS ブックマークレットとして追加して、ワンクリックでデバイスごとの表示を確認 via. Device-Agnostic Approach To Responsive Web Design
同値分割、境界値分析
■チェック用語 ・同値分割 起こりうるすべての事象をいくつかのグループに分け、各グループから 代表値を選ぶ方法です。 このグループを「同値クラス」といい、同様の出力結果が得られる 入力値の集合です。 ・境界値分析 同値クラスの境界値付近を入力値として選んでテストする方法です。 一般的に、ソースコードのバグは境界値付近に潜在することが多いと いわれています。 境界値付近というのは不等号を定義している部分でバグはそこに集中 するという経験則があります。 ・デシジョンテーブル いろいろな条件と 条件に対する行動（起こる事柄）を表形式で書いた ものです。 ■補足 ３歳未満、３歳以上６歳未満、６歳以上でプログラム上の処理が違うときに、 「同値クラス」は、３歳未満、３歳以上６歳未満、６歳以上という３つに 分かれます。 （また、年齢として適当でない数値や数値以外のものも入力される可能性を 考えるならば、
テスト／品質系エンジニアが身に付けておくと得をする7つの技術 - 現場のためのソフトウェア開発プロセス - たかのり日記
「Software Test & Quality Advent Calendar 2011」の初日エントリーとして、書きます！ テスト／品質系のエンジニアも、今や、テストや品質のことだけを知っているだけでは、幸せにはなれない時代となってきています。 プログラムは書けなくても、身に付けておくと良いと思っている技術をまとめてみました。 ※注 今回記述した内容は、以下のような私のドメインに偏ったモノになっています。 ミッションクリティカル／エンタープライズ系 Java／.NET 他のドメインでは異なる部分や他の標準的なツールがあれば、コメントを頂ければと思います。 バージョン管理／課題管理 今や、必須のスキルと言えるでしょう。 バージョン管理（SCM／VCS／DVCS）としては、 集中型のSubversion（SVN） 分散型のGit／Mercurial などが有名ですね。 分散型の場合は、各エ
Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記
このエントリでは，Ruby on Rails （以下 Rails）の ActiveRecord モデルテストについて，1) どこの何をテストすればよいか，2) どのようにテストを書けばよいか，のガイドラインを示します．このガイドラインは Rails 公式のものではなく，id:passingloop が使っている私的なものです．疑問・質問・批判・間違いの指摘はページ下部のコメント欄までお願いします． はじめに Rails は TDD/BDD サポートが充実した Web アプリケーション開発フレームワークです．Rails で使える Test::Unit や RSpec などといったテスティングフレームワークの使い方に関する解説も豊富にあります．しかし，「どこをどうテストすればよいのか」についての解説は，「使い方」の解説と比較して少ないように思います．もっとも，テスト一般についてどう書くかはアプ
デシジョン・テーブルを活用する
整理して表現する 例 基本 表を圧縮する 表を分割する 補完規則 まとめ 整理して表現する 仕様やテスト項目などを文書にまとめるとき、 どのように表現しているでしょうか。 一般に、慣れない人が書くと、 だらだらとした日本語表現になってしまい、 前提条件や実行手順が今一つよくわからない（曖昧になる）、 という状況に陥ってしまうことがあります。 私の周囲でも、 「ユーザからの要求仕様は、物語風で、よくわからない」 と言っている人がいました。 （要求仕様書） の項では、 仕様の曖昧さを解消するための要求仕様の書き方、 表現のしかたについて解説した書籍を紹介しました。 その書籍の中でも少しだけ触れられていますが、 場合によっては、デシジョン・テーブルの形式で表現した方が 明解でわかりやすくなることがあります。 デシジョン・テーブル（ディシジョン・テーブル）は decision table、 つまり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cheat Sheet - Watir - OpenQA Wiki