テストカバレッジ - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TestCoverage.html 「テストカバレッジ(コードカバレッジ)の目標値はどれくらいがいいのか？」という質問とか、コードカバレッジの高さの自慢とかを、ときどき耳にする。でも、大事なポイントを外している。コードカバレッジは、コードのテストされていない部分を発見するための有用なツールである。ただテスト自体がどれだけ良いかという指標としては、テストカバレッジはほとんど役に立たない。 二つ目の例を先に検討してみよう。「カバレッジが87%以上じゃないと本番には入れない」というようなことをやっているところも多いみたいだ。「TDDやっているならカバレッジが100%があたりまえ」という言葉を聞くこともある。賢人が言った: カバレッジが高いことを期待する。マネージャがそう期待することもある。でも微妙な違いがある。 – Brian Mari
TDDを諦めることと、RSpecをやめること - 高柴ラボ
2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の
RSpec をやめて Test::Unit に戻る - tmtms のメモ
最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number
TDDという名の幻想... - Qiita
TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か？です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
TDD/BDDにおける「振る舞い」の意味するところとは何なのか
TDD/BDDにおける「振る舞い」の意味するところとは何なのか：いまさら聞けないTDD/BDD超入門（3）（1/3 ページ） 前回の「TDD／BDDの思想とテスティングフレームワークの関係を整理しよう」では、TDD／BDDについて、その思想と、それをサポートするテスティングフレームワークに分けて解説しました。その中で、TDD／BDDについては実際の熟練者の言葉を借り、テスティングフレームワークについては概要を触れて、その系譜をたどりました。 BDDはその名前に「Behavior」とありますが、「振る舞いとしてのテストコードを書く」とはどういうことなのでしょうか？ 難しく考え過ぎる必要はありませんが、「それは振る舞いを書いていないよ」と指摘をする熟練者が何を考えているかを理解することはBDDを習熟していく中で重要な意味を持ってきます。 本記事では「振る舞い」という言葉がどのような意味で使われ
【翻訳】TDD is Fun - diskogs's diary
@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
TDD is dead. Long live testing. (DHH)
By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen
テストを書く文化を育てる戦略と戦術
at DevLOVE現場甲子園2013 2013/11/09 (土) http://http://devlove.doorkeeper.jp/events/5464Read less
Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
「最強」のチームを「造る」技術基盤
「最強」のチームを「造る」技術基盤 Presentation Transcript 「最強」のチームを 「造る」技術基盤 Nov/09/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/ Hiroyuki Ito (伊藤 宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2 アジャイルコーチとして、 開発現場を日々サポートさせていただいています。 3 造る ＝ 栽培する・耕す 4 CI/CD TDD ATDD この３つを軸にした チーム造りについてお話します。 5 Agenda 1. チーム造りの背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD for Android 4. 3rd Stage : ATDD
TDDの自殺 #kyon_mmAdvent - うさぎ組
はじめに 僕は熱心にTDDを勧めているエンジニアです。 ですが、この2年でTDDが銀の弾丸ではないことも気付き始めました。 その気づきの一つがこのTDDの自殺です。 先にFacebookで投稿したところ、評価をもらえたので投稿します。 「読み手を選ぶエントリーです、(`・ω・´)ｷﾘｯ」 これを読んで「kyon_mmも落ちたものだ」と思ってもらっても構いませんし、「迷惑な話だ」ということであれば僕に猛抗議をしてもかまいません。 TDDとはなにか TDDは開発者を支援するフレームワークと定義します。 TDDは「開発者の意図を確認すること」「開発者が心地よいコードを書き始める事」を支援するフレームワークです。 TDDの基礎 TDDを支えるものとして次の要素があります。 客観的で頻繁にも実施できる検査群、確認し易い検査結果群、RED,GREEN,REFACTORのライフサイクル。 これらによって
PHPer が「JUnit実践入門」を読んだ
「JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)」を献本して頂いたので読んでみました。 普段は PHPUnit でテストを書いているので、その本家とも言える JUnit の本は興味津津でした。 実は、今でこそ PHP 三昧の日々ですが、数年前（JDK1.3 とか 1.4 の時代ですが）は Java で開発していたこともあったので、いまどきの Java、JUnit がどうなっているか知りたくもあり、興味深く読み進めることができました。 読んでみて感じた点を挙げてみます。 1. 圧倒的なボリューム まず目次をざっと見た時に感じたのがカバーしている範囲の広さです。正直よく一冊に収まってるなあと:D JUnit の解説からはじまり、JUnit を使ったテストの書き方、ソフトウェアテスト・テスト技法、ユニットテストのパターン、そして JUnit のより
プロとしての行為 Act as Proffesional
「ソフトウェアのプロになるには本書が必要だ！」と、ボブおじさんがおっしゃっております。 このボブおじさんは、あの有名なアジャイルマニフェストにも名前を連ねているRobert C. Martinです。 プロとしての最低限必要な知識、姿勢、規律など、教育を受けたり学んだことがあるプログラマはあなたの現場に何人ぐらいいるでしょうか？ 今こそ、本書を取って、プロとしての道を歩み始めて欲しい。（amazonでずっと売りきれだったけど、やっと入荷したようだ。すぐに売り切れそうではあるが…） プログラミングの練習 僕はプログラミングの練習というのを意識的にあまりやったことが無い。日本だとTDD Boot Campなどでおこなわれる小さなテーマでプログラミングをおこなうことである。本書の6章に練習について書いてる。 個人的にはRubyKaigiで、ペアプロした外人が、これはToys Programming
TDDに関する記事のリンク集|ネスケラボ
こんにちは、青木です。 これは、TDD Advent Calendar jp: 2011の12/24分のエントリーです。 前日は@irasallyさんのエントリ「職業プログラマに贈るTDDのススメ」です。 翌日は@biacさんのエントリ「TDD とアジャイルを支えるバックボーン」です。 このエントリーではTDD(テスト駆動開発)に関する記事を、一覧に整理しています。 TDDには素晴らしい記事が多く、100を超えるリンク集になっています。 そこで目的に近い記事を探しやすいように、大まかな区分で分類して、内容について簡単なコメントを追記しました。また、昔の記事か最近の記事かわかるように掲載年月も記載しました。 TDDを学ぶときにこのリンク集が役立てば幸いです。 TDDとは ［動画で解説］和田卓人の“テスト駆動開発”講座(Gihyo.jp) http://gihyo.jp/dev/serial/
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
職業プログラマに贈るTDDのススメ #TddAdventJp – 寺子屋未満
このエントリはTDD Advent Calendar jp: 2011のエントリーとなります。 前日の@yuri9976さんのエントリ「TDDと共に（成長記録としてのTDD）」に続く23日目の記事です。 23日目はTDDを初めて2年目のオム子がエントリを担当します。 ラスト3の座をゲットしてしまい、さらに電子書籍化の話…と気が遠くなりそうになっていましたが、がんばります。 まずは、タイトルの「職業プログラマ」って何さ、って話からしましょう。 職業プログラマとは（※オム子定義による） 「プログラミングを職業としているので勤務中はコードを書くがプライベートではほとんど書かない」 「詳細設計書通りにプログラムができていればそれでよい」 「与えられた環境と技術以外のことは求めない」 「コードよりもExcelと向き合っている時間が多い」 「割と大規模なプロジェクトで昔からの文化に染まり、それが常識だ
TDD Boot Camp 横浜で初めてGroovy触ったらかっこよすぎﾜﾛﾀwwww #tddbc - (カチャカチャカチャ…) (ッターン！)
1日たってしまいましたが、11/06にTDD Boot Camp 横浜に参加してきました。詳しい記事は、id:absj31さんの記事が素晴らしくまとまっているので、ご覧くださいませ。 TDD Boot Camp 横浜に参加してきた #tddbc - Diary of absj31 TDD BCの感想と、Groovyを初めて触った感想です Groovyペアに立候補した理由 「募集」をしているわけで、立候補すれば、その場でペア成立 Groovyを触ったことがなくても大丈夫という前提 プログラミング言語好きとしては、Groovy触ってみたかった 普通なら、師匠は直々に、言語のフォースを教えくれない 運営の方と、TDDやったほうが身につきそう！ たしか、こんな理由だったと思います。打算と興味が五分五分といったところでしょうか。運営の方が、Groovy本を持ってきてくれて、 パラパラと見た第一印象は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDDの自殺 #TDDeX
