「TDD is dead. Long live testing」 まとめ - quattro_4 scribble
RailsConf 2014 Is TDD dead? Is TDD dead? [Part II] Is TDD dead? [Part III] Is TDD dead? [Part IV] Is TDD dead? [Part V & VI] （40分くらいの Kent frozen がうける） TDD is dead. Long live testing. (DHH) 翻訳 2014-04-24 - やっとむでぽん 自動化したリグレッションテスティングが存在しないという残念な業界の現状 TDDには感謝しているが、設計の教義としてはとっくに使わなくなっている 間接的で過剰に複雑な構造を生みがちだ。「遅い」ものをすべて避けようとする 伝統的な意味でのユニットテストはほとんどしない。すべての依存関係をモックにし、何千というテストが数秒で終わるようなユニットテスト 我々は完全なシステムテス
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
TDD演習課題 - TODOリストアプリ
TDDeXchange-exercise-for-tdder.md この 作品 は クリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下に提供されています。 背景 TDDeXchange #TDDeX で作成したTDD練習用の課題です。この課題のライセンスはCC BY-SAになります。この課題に対するフィードバックをもらえると著者は喜ぶのでぜひお願いします。 mail : kyon.mm at gmail.com twitter : kyon_mm TODOリスト 環境などの要件 UI コマンドライン、Web両方のバージョンが欲しい 同じようなデザインにする必要はない。 デプロイ スタンドアローン、Webサーバー上両方できるといい。 デプロイするバイナリが個々で異なっていてもいいが、保守性あげたいので出来るだけ共通化してほしい。 データの保持 PCを再起動しても保持され
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
TDDミートアップ に参加しました - Munch Box
もうちょっと早めにアップしておきたかったんですが、 週末の宿題やら、会社の飲み会やらでちょっと遅れてしまいました。 ⇒ まぁ、またまた内容は軽いんですけど。。。 「TDDミートアップ」 http://bit.ly/1at4Wmg 今回は @y_sumida さんがまとめてくれたTogetterに相乗りして、 僕もちょこちょこ呟いてたツイートをマージしたので当日の様子は↓参照、と。 「TDDミートアップ #TDDMeetUp」 http://bit.ly/11nGwHo @y_sumida さんももうブログアップされてますね 「TDD ミートアップに参加しました」 http://bit.ly/11nHT9a あ、それときょんさんが当日発表した資料も（若干追記・修正して） アップされてますね。 http://slidesha.re/16JZyZi さて、テープ起こしレベルで話を書き留めたいんで
TDD ミートアップに参加しました - THE BLUE NOWHERE
TDDミートアップ - connpass TDDミートアップ #TDDMeetUp - Togetterまとめ TDD 実践してないけど面白そうなので行ってきました！ いろんなトピックがあったなかで自分が提案したトピックが取り上げられてよかったです。 ディスカッションした感想というか考えたことを書きました。 TDD とプログラミングパラダイム 個人的に TDD はオブジェクト指向プログラミングと一緒に語られることが多いと感じています。 『テスト駆動開発入門』や『実践テスト駆動開発』では、サンプルコードが Java なので当たり前っぽいですが、『テスト駆動開発による組み込みプログラミング』などは、サブタイトルが "C 言語とオブジェクト指向で学ぶアジャイルな設計" です。 疑問としては手続き型言語で TDD をする場合でもオブジェクト指向な設計に洗練して行くべきなのか？ということでした。*1
Cucumber 再考 - tomykaira makes love with codes
#tddact の LT のなかで cucumber を批判したが(資料: tomykaira/specs-dis)、いろいろ考えて反省したので意見表明する。用語には気をつけているつもりだが、間違って覚えているものがあるかもしれないので、気になる点はぜひ指摘していただきたい。まず、私は cucumber を rails 上の end-to-end な developer test としてしか使ったことがなかった。ようするに開発者が開発を駆動するために書くテストだ。 そうすると、 cucumber にプリセットされている step 定義にのっとり cucumber 語(日本語でもプログラムでもないよみにくいもの)で適当に確認したい動作を書いて、これを実現するようにプログラムを書くということをしていた。 もちろん全部をデフォルトの step 定義で書くことはできないので自分でも拡張しなきゃ
「TDDを明確に定義する」に対する返答 - tomykaira makes love with codes
このエントリは id:kyon_mm さんの TDDを明確に定義する - うさぎ組 にたいするリプライです。拾ってもらえないと悲しい。 TL;DR 私にとって TDD はテストファーストを含む。理由は TDD という語があたえる語感である きょんさんが RED -> GREEN -> REFACTOR と言いながらテストファーストを含まないというのは矛盾を感じる この問題を解決するため、定義を一部具体化したい 本編 一読して、うーん?という部分があったのですが、「テスト」という言葉についてなどの考えを共有したのでほとんど違和感はなくなっていました。上の記事の議論の中核には私はほとんど同意します。私はきょんさんの TDD という言葉の使い方にすこし違和感を感じています。揚げ足取り的になってしまう恐れがありますが、あえてこまかいところを指摘します。TDD = Test Driven Devel
バーチャルパネル: コードとテストの比率、TDD、BDD
JB:この件について一般化するのは嫌なので、私がTDD/BDD使うときとその理由を説明させてください。 私が初めてTDDに出会ったのはミス(欠陥といってもバグといってもいいでしょう）を防ぐ方法を求めていたからです。プログラム上の多くのミスのおかげで私は完璧さの感覚を失ってしまいました。どんなことを成し遂げても仕事が完璧に近づいたと感じたことはありませんでした。そして、書いたコードをテストすれば、ばかげた小さなミスを見つけ修正できるのではないかと考えました。テストをしてミスを見つけたかったのは、愚かにみられるのを防ぐためというより、仕事に対する完璧さの感覚を失わないようにするためです。実際テストは役に立ちました。数年経って、TDDはコーディングのミスを防ぐのに役に立つだけでなく、デザインの失敗を防ぐのにも役に立つことに気づきました。そしてBDDを学び、どのような機能を実装するかについての失敗
[TDD] TDD in Actionに参加してきた - joker1007’s diary
久々にブログ書く。 筆無精は中々直りませんね。 7/22に開催されたTDD in Actionに参加してきました。 TDDBCに近いイベントですが、実際にTDDを実践している人が、 他の人のTDDを、もっとしっかり見てみようぜ、って形をメインにしています。 会場は、青山のオラクル。 いつもお世話になっております。 なんか前日のイベントの余りか何かで、 朝から大量の発泡酒と、ありえない量のハッピーターンが支給されるという、 大分カオスな勉強会になってましたw 朝到着した瞬間から酒の匂いしかしねえ・・・。 TDDBCと同様、基本はペアプロで進めていきますが、 TDD要素があれば、基本何やっても自由というゆるふわルール。 私はそこそこ基本的にやってたつもりですが、 普段からあんまりテストファーストにこだわってないので、 まあ、リモートにpushする前にテスト揃ってりゃいいよねぐらいの感じでやって
![[TDD] TDD in Actionに参加してきた - joker1007’s diary](https://cdn-ak-scissors.b.st-hatena.com/image/square/317c46f1d1e592bcd20ffc13f17c82a26458ef16/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F8599973812290844300%2F8599973812290844672%2F1503340984)
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
Unit testing isn't enough. You need static typing too.
When I was working on my research for my Masters degree I promised myself that I would publish my paper online under a free license, as soon as I had graduated. Unfortunately there seems to be an unwritten rule of Graduate School research. You spend so much time focusing on a single topic of study that by the time you graduate you are sick of it. So more than year later I'm finally putting my pape
TDDの前方依存と後方依存 - pocketberserkerの爆走
『注意』 この記事には間違っているかもしれないことが含まれています。 また個人の意見なので鵜呑みにしないようにしてください。 あと疑問符がついている部分の答えはここには書いてません。 TDD自体は簡単な概念と思う TDDそれ自体は簡単な概念だ。 Red、Green、Refactor…実にシンプルである。 だがしかし、TDDは難しいという話はことあるごとに聞く(ような気がする) 「では何が難しいのだろう？」というわけで脳内で妄想を膨らませてみる。 [追記]前方依存、後方依存という言葉をだしているが、勝手に考えた造語なので項目ごとに定義も追加しておきます。 技術的な前方依存 『TDDを始める前と終TDDを実際やるために必要な技術』 最低限対象言語でコードがかけるようになって 最低限テスティングフレームワークを使えるようになって リファクタリングをしっかり学んで 対象言語でのきれいなコード、設計
ユニットテストの保守性を作りこむ, xpjugkansai2011
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
わんくま同盟
メニュー わんくま同盟 勉強会情報 メンバリスト 掲示板 ブログ リンク わんくま同盟 C#, VB.NET 掲示板 ライセンスオンライン コメント リンクはご自由にどぞ。 上のバナーでどぞ。 バナーは直リンクでどぞ。 09/10 大阪勉強会 #79 上記イベント 申し込み受付中 わんくま同盟 名古屋勉強会 #20 ＆ 第39回 名古屋アジャイル勉強会 ＆ TEF東海 勉強会 後援:/GITCA 今回の勉強会情報 2012年最初のわんくま勉強会は、名古屋アジャイル勉強会及びTEF東海と３つのコミュニティが合同でお贈りする、テスト＆TDDワークショップ！ ※ワークショップ・・・参加者の方が実際に手を動かして学習を行うスタイルの勉強会の事。 ソフトウェア開発におけるテストってなんなのか、テストを行う事で品質は上がるのか、また開発手法の1つであるTDD(テスト駆動開発)ってどうやるのか、参加者の
あなたは写経しますか - pocketberserkerの爆走
@katzchangさんの次となるTDD Advent Calendar jp: 2011の11日目記事になります。 登録者一覧を眺めるたびに「他に学生がいない…」と嘆きつつ、ハードルが上がり続けたタイミングでの担当回というこで胃に穴があきそうです。 11月時点では「TDDBCについて書こう」と思っていたのですが、12/1の素晴らしい記事によって書くことがなくなったり*1、日々追加されていく素敵記事を眺めながらどんな内容にするか悩んだ結果、釣り気味なものになってしまいました… はじめに とりあえず、この10日間に書かれたTDD Advent Calendar記事を振り返ってみましょう。まだ読んでない方は、まずは10日目までの読んでみてください。 まず、TDD少年の想いや学ぶべき理由を知ることができます。そしてTDDを学ぶ前に身に付けておくといいと思う基礎体力が提示され、TDD入門方法の１つ
自動テストのレベル分け
最近は、「xUnit で UnitTest を書いてカバレッジとってます」なんて、どいつもこいつも謳ってるけど、お前らマジかと。それで出来てるつもりなのかと…? というわけで、秋の朝がさわやかなので、自動テストの出来てる度合いの段階区分を考えてみたい。 Level 3: 出来てる：常時テスト成功、高カバレッジ ちゃんとできてるプロジェクトの出来る子ちゃん達からしたら、取り立てて言及することもない当たり前の状態だと思う。 "Clean Check-In" が普通に守られているから、当然、テストも常時全件成功する。まあ基本中の基本。 で、TDD/TestFirst で開発してるから、開発の最初期から高カバレッジ（計測対象範囲内でのカバレッジ基準充足）で始まり、進捗に伴いソースコード量が増えていく中でも、高カバレッジを維持したまま推移する。 Level 2:怪しい：ほぼ常時テスト成功、低カバレッ
JavaプロジェクトでGroovyを導入すべき５つの理由 - うさぎ組
前段 TDDBootCamp in Tokyo 1.5にJavaグループの一員として参加させていただきました。 そこでGroovyをやりたいというホットなエンジニアと出会いまして、GroovyでTDDをさせていただきました。 いきなりGroovyでプロダクトを書く事はなかなかないと思っているので、Javaのプロダクトコードに対して、Groovyのテストコードを書く。という方法で演習しました。 そこで、皆様がGroovyへ多少なりとも注目してくださいましたので、このエントリーを書いてみようと思いました。 JavaプロジェクトでGroovyテストコードを導入すべき５つの理由 以下であげる５つのポイントは「Groovyを知らないJavaプログラマーがすぐに始められるGroovyの強力な機能」をとりあげました。 もちろんここにあげた以外にもたくさんのGroovyの強力な機能はありますが、それらの威
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Limited Red Society
今すぐフォローしておきたいAndroid テストクラスタ