タグ

TDDに関するrochefortのブックマーク (38)

  • テスト駆動開発(TDD)はもう終わっているのか? Part 1 | POSTD

    後編を公開しました(2014/10/8) これは、テスト駆動開発(TDD)とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2~3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の

    テスト駆動開発(TDD)はもう終わっているのか? Part 1 | POSTD
  • Test Yourself - テストを書くと何がどう変わるか

    unassert - encourage reliable programming by writing assertions in productionTakuto Wada

    Test Yourself - テストを書くと何がどう変わるか
    rochefort
    rochefort 2014/09/11
    TDD導入効果がよい。21枚目
  • RSpecとtest-unit 2での抽象化したテストの書き方の違い - 2011-07-12 - ククログ

    Ruby会議2011の3日目の「テスティングフレームワークの作り方」の準備をしていますが、30分だと詰め込み過ぎになってしまうので、話さないことを事前に書いておきます。それは、テストを抽象化するためのAPIの違いです。 RSpecとtest-unit 2でのAPIの違いというと、class UserTest < Test::Unit::TestCaseとdescribe Userやassertとshouldの違いの方が目に付きますが、抽象化するためのAPIにもツールの特徴が出ています。抽象化するためのAPIはテストの量が増えてくると必要になる大事な機能です。ここでは、その中でも「テストを共有するAPI」について考えます。 まず、ツールの考え方について確認し、その後、それぞれのツールでどのようなAPIになっているかをみます。 ツールの考え方 まず、それぞれのツールの考え方について確認しま

    RSpecとtest-unit 2での抽象化したテストの書き方の違い - 2011-07-12 - ククログ
  • TDD のこころ @ OSH2014

    at Open Seminar Hiroshima 2014 (#osh2014) 2014.02.01 (Sat) http://osh-2014.github.io/

    TDD のこころ @ OSH2014
    rochefort
    rochefort 2014/02/08
    絶版多いなぁ。今後は電子書籍で出して欲しい。
  • TDDで「テストばかり書いて間に合うのか?」と質問されたときの正解 - きしだのHatena

    TDDにおいて、顧客などから「テストばかり書いていて間に合うのか?」などと質問されることがあると思います。 そんなときには、後ろからそっと抱きしめて 「そんな質問させてごめんな」 が正解です。 https://twitter.com/kis/statuses/350279800600018944 テスト駆動開発の効果はどのくらいある? − Publickey テスト駆動開発 作者:Kent Beckオーム社Amazon

    TDDで「テストばかり書いて間に合うのか?」と質問されたときの正解 - きしだのHatena
  • 最近やってるRailsプロジェクトのテスト方法 - #詰んでる日記

    Railsエンジニアになってから1年半くらいが経ち、社内のRailsプロジェクトを全部で5つくらい触って、今やってるAbilie*1でようやく人並みにテストを書いてる気がしてきたので、現時点でやってるテストの方法をまとめておく。 テストのルール的なの rspecでは必ずモデルのテストは書くようにしてる。ヘルパーも大体書いてるけど、コントローラやルーティングのテストはあまり書いてない。 というのも、コントローラーのコードを極力短くしてモデルを太らせているのでコントローラのテストはあんまり意味が無い気がしていて、その代わりにCapybaraでテストを書いておけば十分なんじゃないかなと思ってきたから。Capybaraは書いてるので、そういう意味では書いてるとも言える。 社内の管理者だけが使える管理画面も作ってるけど、そっちはテストあんまり書いてない。ここは動かなくなっても一般ユーザーには影響が

    最近やってるRailsプロジェクトのテスト方法 - #詰んでる日記
    rochefort
    rochefort 2012/02/05
    simple-cov 使ってみる
  • Discover gists

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    Discover gists
  • TDDBC東京1.5に参加してきた - b6note

    TDDBCは、みんなでTDDやってみようぜ!ペアプロとかやって他言語/他人間で 理解しあってリスペクトしようぜ!っていうワークショップです。 今回は7/9、TDDBC東京に参加してきました。 今回の発起人は@HIROCASTさんです。 HIROCASTさんのブログエントリはこちらですね。 当日のUSTの記録はこちらですね。 写真はこちらです。 @HIROCASTさん、id:t-wadaさん、スタッフのみなさん、 会場提供されたZyngaJapanさん、参加された皆さん、ありがとうございました。 かなりの参加希望者数で、ATNDは早い段階で人が溢れまくっていました。 ちなみに希望して運営のお手伝いってことで当日の受付をやらせてもらいまして、 ATNDの「設営・受付・運営協力」に「@akitsuka さん」と 書いていただいているんですが、@akitsukaさん(知らない人)は ぜんぜん別の人

    TDDBC東京1.5に参加してきた - b6note
  • Act as Professional |

    プログラマは1日のほとんどを座った状態で生活している人がほとんどではないでしょうか? この「座りすぎ」の毎日は病気のリスクを高くすることが明かになっています。 座りすぎは病気のリスクを高める この「座りすぎ」の生活は2型糖尿病、心血管疾...

    Act as Professional |
  • Request SpecでJavascriptのあるページをテストする方法、 Capybara + Selenium, Capybara + Akephalos など - yuumi3のお仕事日記

    先日リリースした 萌えトーク では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

    Request SpecでJavascriptのあるページをテストする方法、 Capybara + Selenium, Capybara + Akephalos など - yuumi3のお仕事日記
  • RSpecでモックとスタブ - ひげろぐ

    きちんと理解してなかったのでいろんなページを参考にいじくりまわしてみた。 そのメモ。 モックとはスタブとは Martin Fowler’s Bliki in Japanese – TestDoubleの定義がわかりやすいので引用。 スタブは、テスト時の呼び出しに対して、あらかじめ用意された結果を返す。 通常、テスト用にプログラムされたところ以外には応答しない。 スタブは呼び出しの情報を記録することもある。 例えば、Eメールゲートウェイスタブは「送られた」メッセージを記録するような場合だ。 単に「送られた」メールの数を記録する場合もあるだろう。 スタブによってデータベース接続やネットワークIOなどの要素をテストから分離することができる。 また時間のかかる処理をスタブで置き換えることによってテスト時間を短縮することにも使われる。 モックは、エクスペクテーションが事前にプログラムされたものである

  • moroの日記 - Railsでテストを書く勘所

    昨日はOSCに行ってきました。セミナーやブースはほとんど行かず、例によってRubyの会のあたりでだらだらしてたわけですが。 思いがけず師匠の師匠、id:t-wadaさんにもお会いできてびっくり。 で、そこでRailsとTDD(BDD)の話なんかしたので、一週間で思ったことをつらつらと。たぶん不正確というか、理解の足りないところもいろいろあるので、そのへんのツッコミをいただけると感謝です。 書いてたら長くなったのでagenda モデルのテストでは、とにかくロジックを書いたらテストを書く*1。def..endブロック(wを書いたら必ずテストもあるはず。 RailsのMVCコンポーネントの中では一番テストし易いので、そういう意味でもモデルを厚くすると幸せになりやすい。 コントローラのテストでは、基的にリクエストを受けてから表示対象のオブジェクトを導出するまでをテストしたい。 ビューのテストでは

    moroの日記 - Railsでテストを書く勘所
  • Titanium Mobileを二ヶ月くらいさわってみた感想。 - ひげろぐ

    今年に入ってからほぼ毎日触ってました。でもほとんどiPhone開発しかしてない感想。 主観的なところをだらだらと書いてみましょう。 とりあえず気に入っているところイマイチと思うところを挙げてみたい。 合わせて総評など。 気に入っているところ さくさく開発できる Objective-Cとは段違いの開発効率。 冗長なメソッド名とメモリ管理の煩わしさからの解放がうれしい。 ちょっとしたモックアップ程度ならさくっと作れてしまう。 そこから開発者が作り込みに注力できる環境が見事にできあがっているのではないかと。 JavaScriptはくせもあるけどおおむね使いやすい言語。 CoffeeScriptとの組み合わせでさらにいいかんじ。 TDDできる Jasmineで気持ちよくTDD出来ている点が非常にポイント高い。 おかげでTitaniumラブですよ。 Objective-CでもTDD可能だけど、OCU

  • The only one big thing every programmer should know

    The only one big thing every programmer should know - Feb 18, 2011 at Developers Summit 2011

    The only one big thing every programmer should know
  • 翻訳してる人がいるなら手伝いたいから連絡くださいシリーズ - 角谷HTML化計画(2011-02-03)

    ■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

  • TDD のこころ

    The spirit of TDD - Oct 22, 2010 at Cybozu Developers ConferenceRead less

    TDD のこころ
    rochefort
    rochefort 2010/10/29
    私自身tddに注目し始めたのはここ2年くらいだけど、t_wadaさんやkakutaniさんは一貫したことを言ってるなぁ。clean codeとtdd入門は読んでみよう。
  • TDD で作る RakuAPI ライブラリ - 2nd life (移転しました)

    RakuAPI - 楽天市場 非公式ウェブサービス という楽天の非公式 API のライブラリを作るのが流行みたいなので作ってみました。ただそれだけでは面白くないので、最近自分が TDD でライブラリ作るときの方法も軽くご紹介します。 まずはインターフェイスの構想 何はともあれ、どんなインターフェイスを定義して、どんな結果が返ってくるのかがイメージできないとライブラリは作りにくいです。というわけでざっくり最初に構想を練ります。 RakuAPI の場合は WebAPI がシンプルに使えて良い感じなので、構想を練るのに考え込む、というのはありませんでした。 そんなんで、RakuAPI.new でインスタンスを取得して、search メソッドで第一引数に検索文字列、第二引数はオプションでジャンルやプライスを渡せるように、結果は配列にStruct が格納されてる感じにしよう。と考えました。 テストを

    TDD で作る RakuAPI ライブラリ - 2nd life (移転しました)
    rochefort
    rochefort 2010/10/03
    ちと古いけど。メモ
  • RSpec の入門とその一歩先へ、第3イテレーション - t-wada の日記(旧)

    和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第3イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 大きく時間が開いてしまいました(すみません…)、RSpec 入門の第三イテレーションです。 (第3回 coffee.rb の開催に合わせたライブ更新で書かれましたので、まだ詳細の説明は途中のところもあります。) 第1イテレーション 第2イテレーション 前回終了時点のコードと実行結果 この「RSpec 入門とその一歩先へ」シリーズでは、メッセージフィルタを RSpec を使って開発することで、 RSpec の機能と TDD を同時に学ぶことを狙いとしています。 前回終了時点のコードと実行結果をまず記します。 message_filter.rb class MessageFilter def initialize(*w

    rochefort
    rochefort 2010/10/03
    毎度ためになる
  • 「とちぎテストの会議」レポート | gihyo.jp

    2010年7月17日に、栃木県北部の西那須野公民館に30名近くの人が集まり、「⁠とちぎテストの会議」が開催されました。稿では、イベントのレポートをお届けします。 レポート写真協力:佐々木揚さん、中内章一さん 深夜のTwitterから始まった、とちぎテストの会議 イベントは、2月ごろにTwitter上でTDD(テスト駆動開発)をめぐる議論が行われたことが発端となっています。同じ「TDD」という言葉を見たときに想像する内容が人によって大きく異なるらしい、ということがこれらの議論から見えてきたため、「⁠それなら、様々な立場の人を集めて議論してみよう」というところからイベントが企画されました。 TDDはテスト手法か否か(@kdmsnrさんまとめ) TDDについて(@t_wadaさんまとめ) 深夜のテストTL(@fistfvckさんまとめ) TDDネタ再燃?(@vestige_さんまとめ)

    「とちぎテストの会議」レポート | gihyo.jp
  • 三周遅れのXP

    三周遅れのXP - Téléchargez le document au format PDF ou consultez-le gratuitement en ligne

    三周遅れのXP