日本Ruby会議2011の3日目の「テスティングフレームワークの作り方」の準備をしていますが、30分だと詰め込み過ぎになってしまうので、話さないことを事前に書いておきます。それは、テストを抽象化するためのAPIの違いです。 RSpecとtest-unit 2でのAPIの違いというと、class UserTest < Test::Unit::TestCaseとdescribe Userやassertとshouldの違いの方が目に付きますが、抽象化するためのAPIにもツールの特徴が出ています。抽象化するためのAPIはテストの量が増えてくると必要になる大事な機能です。ここでは、その中でも「テストを共有するAPI」について考えます。 まず、ツールの考え方について確認し、その後、それぞれのツールでどのようなAPIになっているかをみます。 ツールの考え方 まず、それぞれのツールの考え方について確認しま
I recently spoke at the Scotland Ruby Conference about interesting testing tools and ideas outside of the Ruby community. The goal was to inspire the Ruby community to push the state of the art in testing. Slides Further Resources QuickCheck – Haskell McErlang – Erlang Midje – Clojure Ioke Zombie.js – Javascript Vows – Javascript TestSwarm – Javascript JUnitMax – Java Industrial Logic – Java Swim
The document discusses how the author stopped worrying and loved DumpRenderTree (DRT), a tool used for testing WebKit. It identifies three main test smells in WebKit tests: 1) obscure tests that are difficult to understand, 2) fragile tests that break easily due to minor changes, and 3) high test maintenance costs due to issues like managing golden files for each platform. It provides examples of
RailsでBDDと言ったらRSpecが圧倒的にポピュラーですね。でもRSpecに馴染めないという人はいませんか？私はx.should == yという書き方からKernelを拡張する実装まで、何もかも独自路線でいく個性の強さについていけません。 しかし同時にTest::Unitの垢抜けなさにもうんざりしていて、何かいいフレームワークはないかと思っていた時にShouldaに出会いました。contextを入れ子にできる柔軟性や、既存のTest::Unitインスタンスの中に書けるとっつきやすさはとても魅力的に見えました。そしてその日からShouldaでテストを書き始めました。 このエントリでは、Shouldaを中心にヘルパーやMochaを使った気持ちのいい開発手法を紹介します。 Shouldaは柔軟でとっつきやすい RSpecの最大の魅力はその書き方にあると思います。しかしその書き方を利用するた
The Current State of the Art In the Ruby world there is a wealth of metrics which can provide insight into our code. Looking at such things as: Structural similar code (Flay) Complexity (Flog) Cyclic complexity (Saikuro) Code smells (Reek) Design issues (Roodi) File change frequencies (Churn) When it comes to metrics involving our tests we have: Code coverage (Rcov) Tools to help identify missed e
デバッグしやすいassert_equalの書き方とデバッグしにくいassert_equalの書き方があるのは知っていますか？1 デバッグしやすいassert_equalの書き方を2パターン紹介します。 まとめたassert_equal まず、1つ目のよくみるデバッグしにくいassert_equalの書き方です。 def test_parse assert_equal(29, parse_integer("29")) # (1) assert_equal(29, parse_integer("+29")) # (2) assert_equal(-29, parse_integer("-29")) # (3) end これがデバッグしにくいのは、(1)が失敗したら(2)、(3)が実行されないからです。すべてのassert_equalが実行されて、どのassert_equalが失敗したかを確認す
最近はユニットテストを行うテストコードにおいて、Test Doubleを多用してます。Test DoubleとはMockとStubを合わせた総称です。Test Doubleを用いると、信頼性や保守性が下がると言われることがあります。しかし、それはTest Doubleの用法を誤っているためではないかと僕は思うのです。Test Doubleの用途はユニットテストのスコープをテスト対象のクラスに限定するために用いるべきものです。実感として、Test Doubleを使っているからと言って、ユニットテストの信頼性/保守性が下がったとはあまり感じていません。 良く誤解されていますが、Test Doubleはスローテスト問題を解決するための手段ではありません。Test Doubleをうまく利用すれば、結果的にスローテスト問題を解決できます。しかし、スローテスト問題を解決するための手段ではないのです。ス
このウェブサイトは販売用です！ twiwt.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、twiwt.orgが全てとなります。あなたがお探しの内容が見つかることを願っています！
The document discusses Extreme Programming (XP) and acceptance testing techniques like customer tests, behavior driven development (BDD), and Fit. It explains how these practices emphasize collaboration between customers, developers and testers to ensure software meets requirements through conversation and executable specifications using examples with formats like Given, When, Then.Read less
Unit Testing in Clojure One thing I love about Clojure is the built in unit tests. Unit tests are great for making sure your code does what it needs to do and introducing new features or bug fixes doesn't break anything. You can refactor your code anytime you want and be sure that you did not break anything. Unit tests also serve as a living documentation for your code base, newcomers can look at
Jasmine: BDD for Javascript | Jasmine 先日プッシュした Jasmine についてもう少し掘り下げていきます。ただしテストの書き方については触れません。それは公式の情報やすでに詳しく紹介されている記事があります。 まとめJasmine は見た目だけでなく考え方も RSpec の影響を受けているよ多少遠回りでも rubygems 版の Jasmine を使うとテストが本当に自動化できるよわざわざツールを使ってテストしたいということはある程度アプリケーションとして規模が大きいとか、サイトとして規模が大きく JavaScript の数が多くなっているので、人力チェックが大変だということではないでしょうか。 規模が大きくなってきた場合は、ある程度作法（ルール）を用意してそれを守ることが安全、安心なアプリケーションの開発、作成に欠かせません。Jasmine は単に
最近何かと話題の Node.js． http://nodejs.org/ Node.js 日本ユーザグループもあります． http://groups.google.co.jp/group/nodejs_jp ドキュメントの翻訳もされてます (リリースされたばかりの 0.2.2 対応済み！)． http://nodejs.jp/nodejs.org_ja/ そんな Node.js 向けのテスティングフレームワークもたくさんあります． http://github.com/ry/node/wiki/modules#testing このモジュール一覧だけでも Node.js 界隈の盛り上がりっぷりが感じられますが，そんな中から Vows というテスティングフレームワークで遊んでみたので紹介します． http://vowsjs.org/ ちなみに，これだけたくさんある中から Vows を選んだのは，
describe("Jasmine", function() { it("makes testing JavaScript awesome!", function() { expect(yourCode).toBeLotsBetter(); }); }); Documentation User Guide Release Notes API Documentation Contributor Guide Download For pure JavaScript projects: VersionSizeDateSHA1
authorize (username, password) basic_authorize (username, password) Basic認証でログインする。 digest_authorize (username, password) Digest認証でログインする。 get (uri, params = {}, env = {}, &block) GETリクエストを送る。 MockResponseを返す。(これが、次にlast_responseを呼んだときの返り値になる。) ブロックを渡した場合、MockResponseを引数にそのブロックを実行する。 例： header (name, value) head (uri, params = {}, env = {}, &block) HEADリクエストを送る。 post (uri, params = {}, env = {}, &
(2014/6/3 追記) MailCatcher がおすすめです。 MailCatcher (追記おわり) メールをどこにも送らずHTMLで保存するSMTPサーバ mocksmtpd.rb - こせきの技術日記 が評判よかったので、気をよくしてgithubでgemを作ってみました。 http://github.com/koseki/mocksmtpd/ インストール方法 $ gem sources -a http://gems.github.com $ sudo gem install koseki-mocksmtpdgem本体を最新版にしといたほうがいいかもしれません。 使い方 一番簡単な使い方。 # 設定ファイル、ディレクトリを作成。 $ mocksmtpd init # コンソールモードで起動。 $ cd ./mocksmtpd $ sudo mocksmtpdinitで設定ファイ
まともなのないかな。「まとも」の評価条件は 堅牢性: プロセス管理やタイムアウト管理などがしっかりしている。 汎用性: いろんなプロジェクトに適用できる。 1.9: ruby 1.9 で動く。今なら当たり前。 chkbuild akr さん作の ruby 用 CI ツール。 http://cvs.m17n.org/viewcvs/ruby/chkbuild/ 堅牢性: ◎ スーパー akr さんパワー 汎用性: × ほぼ ruby 専用。ソースコードがむずかしくて手を入れにくい。 1.9: ○ たぶん 質実剛健というか、「ハッカーが作りました」という感じが漂う。ビルドやテスト中に暴走したプロセスが残るとかのケアはしっかりしてそう。ちょっと使いにくい。 cerberus 主に Rails 向けの CI ツール。gem で入れられる。 http://cerberus.rubyforge.org
■ [ruby] Rubyのテスト環境大戦争 おまいらは本当にテストが好きだな！というわけで、Rubyのテスト関係のライブラリを並べてみた。 テストフレームワーク Test::Unit Ruby標準添付のユニットテスト用フレームワーク。 RSpec DSLを使う、「BDD」という概念を流行らしたユニットテスト用フレームワーク。 Cucumber 自然言語を使って、ブラックボックステストを記述する。RSpecの「Stories」と呼ばれていた機能が独立した。 あとはShouldaとかbaconとかいろいろありますけども。 モック・スタブライブラリ モック＝あるオブジェクトに期待したメッセージが飛ぶかどうかテストするためのオブジェクト、 スタブ＝ネットワークが絡むとか、実際のオブジェクトが使えない場合に使う偽オブジェクト。 と思ってるんですけどどうなんですかね(more: モックとスタブの違い
_ Purely testing Type-driven testing in Haskell (Simon Peyton Jones)より。 Simon の主張はいつもすばらしいのだけど、この発表に関しては Summary に首をかしげる人もいるかもしれない(わたしもその一人): Over the next 10 years, the software battleground will be the control of effects To succeed, we must shift programming perspective from imperative-by-default to functional-by-default A concrete example: testing Functional programs are far easier to test A fu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
