後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
日本Ruby会議2011の3日目の「テスティングフレームワークの作り方」の準備をしていますが、30分だと詰め込み過ぎになってしまうので、話さないことを事前に書いておきます。それは、テストを抽象化するためのAPIの違いです。 RSpecとtest-unit 2でのAPIの違いというと、class UserTest < Test::Unit::TestCaseとdescribe Userやassertとshouldの違いの方が目に付きますが、抽象化するためのAPIにもツールの特徴が出ています。抽象化するためのAPIはテストの量が増えてくると必要になる大事な機能です。ここでは、その中でも「テストを共有するAPI」について考えます。 まず、ツールの考え方について確認し、その後、それぞれのツールでどのようなAPIになっているかをみます。 ツールの考え方 まず、それぞれのツールの考え方について確認しま
42. FizzBuzz問題 Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”. 1から100までの数をプリントするプログラムを書け。ただし3 の倍数のときは数の代わりに｢Fizz｣と、5の倍数のときは ｢Buzz｣とプリントし、3と5両方の倍数の場合には｢FizzBuzz｣と プリントすること。 http://tickletux.wordpress.com/2007/01/24/us
Railsエンジニアになってから1年半くらいが経ち、社内のRailsのプロジェクトを全部で5つくらい触って、今やってるAbilie*1でようやく人並みにテストを書いてる気がしてきたので、現時点でやってるテストの方法をまとめておく。 テストのルール的なの rspecでは必ずモデルのテストは書くようにしてる。ヘルパーも大体書いてるけど、コントローラやルーティングのテストはあまり書いてない。 というのも、コントローラーのコードを極力短くしてモデルを太らせているのでコントローラのテストはあんまり意味が無い気がしていて、その代わりにCapybaraでテストを書いておけば十分なんじゃないかなと思ってきたから。Capybaraは書いてるので、そういう意味では書いてるとも言える。 社内の管理者だけが使える管理画面も作ってるけど、そっちはテストあんまり書いてない。ここは動かなくなっても一般ユーザーには影響が
TDDBCは、みんなでTDDやってみようぜ！ペアプロとかやって他言語/他人間で 理解しあってリスペクトしようぜ！っていうワークショップです。 今回は7/9、TDDBC東京に参加してきました。 今回の発起人は@HIROCASTさんです。 HIROCASTさんのブログエントリはこちらですね。 当日のUSTの記録はこちらですね。 写真はこちらです。 @HIROCASTさん、id:t-wadaさん、スタッフのみなさん、 会場提供されたZyngaJapanさん、参加された皆さん、ありがとうございました。 かなりの参加希望者数で、ATNDは早い段階で人が溢れまくっていました。 ちなみに希望して運営のお手伝いってことで当日の受付をやらせてもらいまして、 ATNDの「設営・受付・運営協力」に「@akitsuka さん」と 書いていただいているんですが、@akitsukaさん（知らない人）は ぜんぜん別の人
プログラマは1日のほとんどを座った状態で生活している人がほとんどではないでしょうか？ この「座りすぎ」の毎日は病気のリスクを高くすることが明かになっています。 座りすぎは病気のリスクを高める この「座りすぎ」の生活は2型糖尿病、心血管疾...
先日リリースした 萌えトーク ではEnd-to-Endテストには Request Spec + Capybara を使っていますが、Javascriptの部分は適当なヘルパーメソッドを使いJavascriptを動作させずにテストしましたが、Capybara のドライバーを selenium や Akephalos (HTMLUnit)に入れ替える事で実際にJavascriptを動かして End-to-Endテスト を行う事が出来ます。 写真は、World's Largest Rodent Born at San Diego Zoo! - ZooBorns より テスト対象 Scaffoldが作った一覧ページに、jQuery を使いShowをクリックした場合showページに遷移せず、一覧画面の下の方の にTodo内容を表示さいます。 app/view/index.html.erb <h1>L
きちんと理解してなかったのでいろんなページを参考にいじくりまわしてみた。 そのメモ。 モックとはスタブとは Martin Fowler’s Bliki in Japanese – TestDoubleの定義がわかりやすいので引用。 スタブは、テスト時の呼び出しに対して、あらかじめ用意された結果を返す。 通常、テスト用にプログラムされたところ以外には応答しない。 スタブは呼び出しの情報を記録することもある。 例えば、Eメールゲートウェイスタブは「送られた」メッセージを記録するような場合だ。 単に「送られた」メールの数を記録する場合もあるだろう。 スタブによってデータベース接続やネットワークIOなどの要素をテストから分離することができる。 また時間のかかる処理をスタブで置き換えることによってテスト時間を短縮することにも使われる。 モックは、エクスペクテーションが事前にプログラムされたものである
昨日はOSCに行ってきました。セミナーやブースはほとんど行かず、例によってRubyの会のあたりでだらだらしてたわけですが。 思いがけず師匠の師匠、id:t-wadaさんにもお会いできてびっくり。 で、そこでRailsとTDD(BDD)の話なんかしたので、一週間で思ったことをつらつらと。たぶん不正確というか、理解の足りないところもいろいろあるので、そのへんのツッコミをいただけると感謝です。 書いてたら長くなったのでagenda モデルのテストでは、とにかくロジックを書いたらテストを書く*1。def..endブロック(wを書いたら必ずテストもあるはず。 RailsのMVCコンポーネントの中では一番テストし易いので、そういう意味でもモデルを厚くすると幸せになりやすい。 コントローラのテストでは、基本的にリクエストを受けてから表示対象のオブジェクトを導出するまでをテストしたい。 ビューのテストでは
今年に入ってからほぼ毎日触ってました。でもほとんどiPhone開発しかしてない感想。 主観的なところをだらだらと書いてみましょう。 とりあえず気に入っているところイマイチと思うところを挙げてみたい。 合わせて総評など。 気に入っているところ さくさく開発できる Objective-Cとは段違いの開発効率。 冗長なメソッド名とメモリ管理の煩わしさからの解放がうれしい。 ちょっとしたモックアップ程度ならさくっと作れてしまう。 そこから開発者が作り込みに注力できる環境が見事にできあがっているのではないかと。 JavaScriptはくせもあるけどおおむね使いやすい言語。 CoffeeScriptとの組み合わせでさらにいいかんじ。 TDDできる Jasmineで気持ちよくTDD出来ている点が非常にポイント高い。 おかげでTitaniumラブですよ。 Objective-CでもTDD可能だけど、OCU
The document discusses the benefits of exercise for both physical and mental health. It notes that regular exercise can reduce the risk of diseases like heart disease and diabetes, improve mood, and reduce feelings of stress and anxiety. Exercise is also credited with boosting brain health and improving cognitive function as we age.Read less
■1 翻訳してる人がいるなら手伝いたいから連絡くださいシリーズ すでにカミングアウトしているように、いまは"The Agile Samurai"の翻訳作業があったり、他にもあれやこれやそれやがあるので余力がなく、カッとなってガーッとやるんじゃなくて、きちんとした品質のものを届けられるといいなあと思っているものが2つあるから書いとこ(TwitterにpostしたらfavとかRTしてもらえたので、需要あるのかもしれないなあと思って)。 "Agile @ 10" on PragPub—February 2011 by Andy Hunt, Kent Beck, Ron Jeffries, Jon Kern, Ken Schwaber, James Grenning, Arie van Bennekum, Stephen J. Mellor, Ward Cunningham, and Dave T
RakuAPI - 楽天市場 非公式ウェブサービス という楽天の非公式 API のライブラリを作るのが流行みたいなので作ってみました。ただそれだけでは面白くないので、最近自分が TDD でライブラリ作るときの方法も軽くご紹介します。 まずはインターフェイスの構想 何はともあれ、どんなインターフェイスを定義して、どんな結果が返ってくるのかがイメージできないとライブラリは作りにくいです。というわけでざっくり最初に構想を練ります。 RakuAPI の場合は WebAPI がシンプルに使えて良い感じなので、構想を練るのに考え込む、というのはありませんでした。 そんなんで、RakuAPI.new でインスタンスを取得して、search メソッドで第一引数に検索文字列、第二引数はオプションでジャンルやプライスを渡せるように、結果は配列にStruct が格納されてる感じにしよう。と考えました。 テストを
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第3イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 大きく時間が開いてしまいました(すみません…)、RSpec 入門の第三イテレーションです。 (第3回 coffee.rb の開催に合わせたライブ更新で書かれましたので、まだ詳細の説明は途中のところもあります。) 第1イテレーション 第2イテレーション 前回終了時点のコードと実行結果 この「RSpec 入門とその一歩先へ」シリーズでは、メッセージフィルタを RSpec を使って開発することで、 RSpec の機能と TDD を同時に学ぶことを狙いとしています。 前回終了時点のコードと実行結果をまず記します。 message_filter.rb class MessageFilter def initialize(*w
2010年7月17日に、栃木県北部の西那須野公民館に30名近くの人が集まり、「とちぎテストの会議」が開催されました。本稿では、本イベントのレポートをお届けします。 本レポート写真協力：佐々木揚さん、中内章一さん 深夜のTwitterから始まった、とちぎテストの会議 本イベントは、2月ごろにTwitter上でTDD（テスト駆動開発）をめぐる議論が行われたことが発端となっています。同じ「TDD」という言葉を見たときに想像する内容が人によって大きく異なるらしい、ということがこれらの議論から見えてきたため、「それなら、様々な立場の人を集めて議論してみよう」というところから本イベントが企画されました。 TDDはテスト手法か否か（@kdmsnrさんまとめ） TDDについて（@t_wadaさんまとめ） 深夜のテストTL（@fistfvckさんまとめ） TDDネタ再燃？（@vestige_さんまとめ）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く