RSpec3初心者向けの資料まとめ直しました！[Ruby]
TDDでRSpecを書くにあたって、どれだけ効率的に効果的なテストが書けるかは、品質を高めていく上ですごく大切なことだと思います。 今回、RSpec3用のドキュメントやWebサイトをいろいろ読みなおして、最近までに特に良かった記事などを中心にまとめ直しました。 RSpec3に入門しようとしている初心者さんや、普段使っているけどもう一度RSpec3の知識を整理したい人にオススメのマトメです！ 🗽 TDD/BDDとは？TDD/BDDにおける「振る舞い」の意味するところとは何なのか RSpecに限定された記事ではないですが、BDDの根本的な概念の「振る舞い」についてまとめられた記事です。 これを知っておくことで、ここから先の話がかなりスムーズに理解できるようになると思います。 🎂 まずテスト書いてからコード書くシンプルなチュートリアルはじめてのRSpec - まずテスト書いてからコード書くシ
![RSpec3初心者向けの資料まとめ直しました！[Ruby]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
最近の RSpec 情勢 - moroの日記
よしみさんの http://d.hatena.ne.jp/walf443/20070324/1174702913 の記事の補足。 最近のバージョンでは Matchers を自分で追加して should のあとに書ける語を増やします。というかそれを実現するために should とそれを受けるプロキシに分離し、あの賛否が分かれる文型になったわけです。わたしゃいい加減なれてきましたが、確かに前の方が好きだったという思いは消えません:p。 カスタム Matchers の作り方 で、こちらを見るとカスタム Matchers の作り方が解説してあります。 http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html 重要なところを(文が通るように加工した上で)コピペすると、こんな感じになります。 module CustomGameMather c
ユーザストーリーから始めるTDD - ヱビスブログ
ヱビスブログ :: ユーザストーリーから始めるTDD TDD from starting from user stories - a top-down styleを日本語でザックリまとめました。 意味を明らかに取り違えているようなところがありましたら指摘してください。 ------------- TDDのルールは最初にテストを書く事だ。現実世界のプロジェクトの多くは、ソフトウェアがGUI、Web、データベースや外部システムとの依存を含んでいる。大概これらはJUnitクックブックのサンプルほどシンプルではない。プロジェクトが異なれば、TDDの実装方法も異なる。例えばテスターが受け入れテスト記述の責務を取り、開発者はユニットテストを書く。TDDer向けにユーザストーリーから始めるトップダウンなTDDスタイルを提唱したい。 ユーザストーリーから始めるTDD What? ユーザスト
BDD = Behavior Driven Development - テストの視点から仕様の視点へ：An Agile Way：オルタナティブ・ブログ
以前のブログで、テストをデザインの手段として捉える、TDD(Test Driven Development)の発展として、BDD(Behavior Driven Development)について紹介した。要は、テストにまつわるボキャブラリから、仕様周辺のボキャブラリに変更することから生まれる、新しい開発の捉え方だ。例えば、Stackが生成時に空であるという仕様を、こう表現する。 shouldBeEmpty() { Stack stack = new Stack(); Verify.that(stack.isEmpty); } 以前の、test, assert というボキャブラリではなく、should, verify というボキャブラリへの転向。 このBDDの本に関する、先行和訳の試みを、懸田さんが始めた！http://log.giantech.jp/BDDIntro-ja.html 要チェ
テスト駆動開発のテストは、テストか？―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]
アジャイル開発の中の１つのプラクティスであるTDD(Test Driven Development、テスト駆動開発)に使われるユニット・テスト、というものの役割について、よくテスト界の人との意見の相違がある。テストとしての完全性、や、品質保証についての考え方から見ると、テストとは呼べないのでは？ということ。 最近、アメリカテスト界の有名人であり、アジャイルコミュニティへの貢献も大きい、Brain Marick(www.testing.com/cgi-bin/blog) 氏とメールで話す機会があった。 アメリカでのコンセンサスは、TDDのテストはテストとしては二義的であり、一義的には、「設計ツール」だ これは、以前「テストの役割=進捗管理＋設計戦略」 blogs.itmedia.co.jp/hiranabe/2005/08/sd4__c05e.html で 紹介した、t-wadaさんの「テス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RSpec ruby DSL for spec driven
http://tcgrim.blogspot.com/2005/12/jbehave.html