Everyday Rails - RSpecによるRailsテスト入門
みなさんはこんなふうにRailsアプリケーションを作ったことはありませんか？たとえば、ブラウザをポチポチとクリックするだけでテストを終わらせて「たぶん大丈夫」と思い込んだり、「とにかく全部うまくいきますように」とただ祈るだけだったり……。 心配しないでください。それは誰もが通る道です。アプリケーションのテストやテスト駆動開発はRails開発における重要なトピックですが、巷の参考書を見ると適当な説明で済ませているものも多かったりします。本書「Everyday Rails - RSpecによるRailsテスト入門」では、どのようにして私がそうしたテクニックを身につけたのか、そして、どのようにしてコードの信頼性を上げ、ブラウザ上で延々とテストしなくて済むようにしたきたのかをみなさんに説明します。 対応バージョンについて2024年1月のアップデートで、本書のコンテンツをRails 7.1とRSpe
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
serverspec インフラ層のテスト項目を考える | Ore no homepage
最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
テスト分析・テスト設計入門
© 2013 Fuji Xerox Co., Ltd. All rights reserved. ■JaSST 2013 四国 テスト分析・テスト設計入門 富士ゼロックス株式会社 ソリューション・サービス開発本部 秋山 浩一 2 自己紹介 1985年4月 富士ゼロックス入社 現在はHAYST法のコンサルティング業務に従事 NPO ソフトウェアテスト技術振興協会（ASTER） 理事 JaSST東京実行委員（2003年～） 日本最大のテストシンポジウム1600名の動員 JSTQBステアリング委員（2006～） テスト技術者資格認定を行う国際組織日本支部 日科技連 SQiP研究会 委員長（2011年～） Wモデル研究会 主査（2011年7月～） 電通大 西康晴先生、NEC 吉澤智美氏、MRT 鈴木三紀夫氏 ISO/IEC JTC 1/SC7 WG26委員（20
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
RSpecのshouldはもう古い！新しい記法expectを使おう！
というように書くようになりました。 別にshouldを使った記法がなくなったわけではありませんが、 https://github.com/rspec/rspec-expectations のREADME.mdには、もう新しいSyntaxの説明しか載っていないし、今後はexpectの方を使っていくほうがいいでしょう。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax には、新しいSyntaxを導入した背景が説明されています。 簡潔に書くと、shouldだとBasicObjectを継承したクラスのテストを書くときに不具合が起こるみたいですね。 移行方法 基本 基本的には、上に書いたように、 foo.should を expect(foo).to に foo.should_not を expect(foo).
テストダブル - Martin Fowler's Bliki in Japanese - TestDouble
http://martinfowler.com/bliki/TestDouble.html Gerard Meszarosが、様々なXunitフレームワークを使用したパターンを集めた書籍を執筆中である。 彼は、ある厄介なことに出くわしている。 システムの一部分をテストするためにスタブ化することがあるが、 その名前というのが、スタブ、モック、フェイク、ダミーなど、色々とあるのだ。 そのため彼は、自身の用語集を作成した。 この用語集は広く普及すべきものだろう。 彼が一般的な用語として使っているのは、「Test Double（テスト代役）」という言葉だ（スタントの代役(double)を想像してほしい）。 Test Doubleは、テスト用にオブジェクトを入れ替えるときに一般的に用いられる言葉である。 Gerardが作成したリストには、様々なDoubleが載っている。 ダミーオブジェクトは、受け渡
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 直
JS開発におけるTDDと自動テストツール利用の勘所
1. JS開発における TDDと自動テスト ツール利用の勘所 2012.12.06 株式会社マピオン 中村 浩士 12年12月5日水曜日 2. 自己紹介 中村 浩士 ( @kozy4324 ) 株式会社マピオン所属 主にWebアプリのフロントエンド開発 JavaScript, ActionScript 12年12月5日水曜日
ちゃんとテスト書き始めた話 - AnyType
テストのモチベ＝怖いからやる 正直に白状すると、「これまでテスト書いたことない && 会社にテストの文化がない && テスト書いてる時間ない」っていう状況で、時間を割いてでもテストを書こうっていうモチベがなかなか湧かなかった。 そんななか、唯一、ハッキリとしたわかりやすいモチベは「デグレが怖い」という恐怖心から解放されることだった。 プロジェクトが大きくなるほど、自分が書いたコードがどこまで影響するか把握できなくなってくる。だからといって、変更のたびにブラウザでポチポチ一個ずつ確認する作業はだるい。 テストが通ってるという事実が抜群の安心感をもたらすことがわかってきて、ちゃんとテストを書くようになったというお話です。 500返ってないか怖い 一番わかりやすいテスト項目として「ユーザーにエラー画面を表示していないか」というのがまずアタマに浮かんだ。 モデルとか変更すると、影響範囲よくわからな
JMeterで負荷計測やってみた - 基本へ帰ろう
what 負荷テストを行ったのでそのメモ 負荷計測ツール JMeter を利用しました。 負荷計測環境のポイント 参考 => 5.JMeterでのテストの作成・実行 また、以下の点などにも気をつけてください ・JMeterを起動するマシンとテスト対象マシンを分ける →同一のマシン上で動作させると、正確な測定結果を得られません ・最初の内は、JMeterを起動するマシンとテスト対象マシンは同一ネットワーク内に配置する →パフォーマンスが悪かった場合など、ボトルネックがネットワークにあるのか、テスト対象マシンにあるのか、判別がつきづらくなります 今回は、『JMeterを動かすPC』をWindowsで動かし、『テスト対象マシン』をLinuxにしました。 負荷計測結果 Throughput 結果 160 ( 160.7017781 ) でした。 スレッド数 200 までは、上昇しますが、それ以降は
ab を用いた簡易的な性能・負荷テストの雛形
Web サービスをリリースするにあたり避けては通れない（避けて通ってはいけない）性能・負荷テスト工程。 ウォーターフォールやアジャイルなど開発手法は様々ありますが、現実問題、概ね開発工程が遅延する傾向があります。なんとか単体テスト・結合テスト・システムテストはやりきるものの、力尽きて性能・負荷テストを実施せずにリリース・・・なんてことはありませんでしょうか？ そんな場合に限って、リリース直後に高負荷でサービスダウン・・・なんてことになりがちです。 そうならないために性能・負荷テストは必ず実施すべき項目です。ツールとして JMeter がメジャーですがシナリオ作ったり、使い方覚えたりと、正直面倒です。でも apache bench なら使ったことあるし知ってる！という方も多いことでしょう。そこで僕が "簡易的" に性能・負荷テストで使っている方法を公開します。 ab を用いた簡易的な性能・負
Ruby on Railsのテストの書き方 （モデルの単体テストと，コントローラの機能テスト） - 主に言語とシステム開発に関して
Ruby on Rails のテストの書き方のまとめ。 RSpecを使わない，素の unit test (モデルのテスト) functional test（コントローラ＋ビューのテスト） について，どう書いたらいいのか，どこの情報を参照したらよいのか，などを列挙。 Rails入門者が初めてテストを書く際に迷わせないようにするためのガイドライン形式。 Railsのバージョンは1.2系を想定。 総説 一度は目を通すべき，入門用のリンク集： RubyOnRails を使ってみる 【第 6 回】 テストの書き方 http://jp.rubyist.net/magazine/?0013-RubyOnRails Railsでテストを書く勘所 http://d.hatena.ne.jp/moro/20061029/1162116778 Railsでのテスト http://d.hatena.ne.jp/a
勉強会/Railsによるテスト作成 - アークウェブシステム開発SandBox
準備 † DBテーブルは下記を使う(テーブル名、カラム名はRailsの規約に従う） -- books create table books ( id integer primary key, title varchar(255) not null, description text, updated_at datetime ); このテーブルスキーマをdb/schema.sqlとして保存し、下記でデータベースを作成する(SQLiteを使用） # cd db # sqlite3 gentest.db < schema.sql 接続情報をconfig/database.ymlに記載する development: adapter: sqlite3 dbfile: db/gentest.db モデルクラス(Book)のスケルトンを作成する # ruby script/generate model
A/Bテストの数理 - 第1回：人間の感覚のみでテスト結果を判定する事の難しさについて - - doryokujin's blog
データ解析の重要性が認識されつつある（?）最近でさえも，A/Bテストを始めとしたテスト（ = 統計的仮説検定：以後これをテストと呼ぶ）の重要性が注目される事は少なく，またテストの多くが正しく実施・解釈されていないという現状は今も昔も変わっていないように思われる。そこで，本シリーズではテストを正しく理解・実施・解釈してもらう事を目的として，テストのいろはをわかりやすく説明していきたいと思う。 スケジュール スケジュール 第1回 [読み物]：『人間の感覚のみでテスト結果を判定する事の難しさについて』：人間の感覚のみでは正しくテストの判定を行うのは困難である事を説明し，テストになぜ統計的手法が必要かを感じてもらう。 第2回 [読み物]：『「何をテストすべきか」意義のある仮説を立てるためのヒント』：何をテストするか，つまり改善可能性のある効果的な仮説を見いだす事は，テストの実施方法うんぬんより本質
「ソフトウェア設計とは何か？」がすごい - Lism.in * blog - nekoya (id:studio-m)
結構前のエントリになりますが、cles::blogさんで紹介されている「プログラミングは設計か製造か？」に感銘を受けました。はてブを見ていると、最近になってwebarchiveから発掘されたようです。 ソフトウェア設計とは何か？ 原文はこちらで公開されている模様。 What Is Software Design? by Jack W. Reeves - developer.*, Developer Dot Star 全編にわたって非常に示唆に富んだ内容となっています。印象深かったトピックは以下。 ソースコードは設計であり、ドキュメントである ソフトウェア開発における「製造」とはビルドである 製造はコンパイラとリンカの仕事であり、コストは非常に小さい テストやデバッグは設計の検証と洗練のプロセスである 他の工学分野のそれと等価で手を抜くべきでない 「コーディング」「テスト・デバッグ」「（俗に
俺のRails開発環境
4. 概要 使ってるもの 無いと始まらないGem rvm rspec vim pry zsh guard screen tapp git 開発に使ってるOS jenkins Mac Linux (Ubuntu, Gentoo) 2012年5月16日水曜日 5. テスト • ユニットテスト • RSpec • インテグレーションテスト • cucumber • javascriptユニットテスト • jasmine-headless-webkit 2012年5月16日水曜日 6. Railsへの入口 • rvmで適当にgemsetを作り、railsをインス トール • rails new appname -T -m <template gist> --skip-bundle • bundle install --path vendor/bundle 2012年5月16日水曜日 7. テストの
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
