wtnabe, yet another yak shaver @wtnabe @kyon_mm 結局のところ、1) サイクルがあること、2) サイクルが重くなりにくいこと、が満たせるかどうかなんじゃないですかね。TDDは最も小さくて速いサイクルを実現するのに向いてる。 2020-02-25 09:54:34
TDDへの違和感をつかめた気がする
wtnabe, yet another yak shaver @wtnabe @kyon_mm 結局のところ、1) サイクルがあること、2) サイクルが重くなりにくいこと、が満たせるかどうかなんじゃないですかね。TDDは最も小さくて速いサイクルを実現するのに向いてる。 2020-02-25 09:54:34
テスト駆動開発（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という名の幻想... - 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は死んだ。テスティングよ栄えよ。 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 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
こくちーずプロ - 無料で使えるイベント・セミナーの告知・集客サービス
個人から法人まで幅広い主催者の方にご活用いただいています。 イベント主催者6万人以上 チケット販売380万枚以上
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
TDD的にiOSアプリケーション開発してみる - yaakaito::Blog
Test, Objective-C, iPad, iPhone(iOSのテストを書くとViewControllerがコントローラーになれる話 - yaakaito::Blog を先に見ておくと、何がやりたいか分かり易いかもしれません。)iOSアプリケーションのテストの書き方、難しいですよね。僕もよく分からないので手探り状態です。とりあえず、標準のOCUnit使ってTDDっぽいことしてみれば、何か叩き台になるかな？と思ったのでその過程を公開してみます。書くテストロジックテストだけです。後々アプリケーションテストもやる予定なのですが、というか一緒にやってたんですが、重すぎたので一旦ロジックテストだけです。ロジックテスト主体で書けるようにできる限りViewContollerと切り離してコードを考えています。ツッコミ大歓迎！(ロジックテストだけやるので、ビューに表示するところまで書いてません)リク
iPhoneでRSpec風テスト - 一足お先に。 −高専出身者が語る技術者ブログ−
三三のエンジニアが、誰一人としてこのブログにリアクションしてくれない事を、密かに気にしている中森です。こんにちは。 Yammerというツイッターっぽい企業向けのものがあり、弊社ではそれを利用しています。 しかし、そこにポストしてもエンジニアがLikeをつけてくれた時は過去ありませんでした。 ちくしょう！ しかし俺たちの戦いは始まったばかりだ！ もうちょっとObjective-Cが浸透すればコメントもらいやすいんですけどね…。 まぁ、私はObjective-C自体は嫌いですから、広まったらそれはそれで困りますけど。 あと、実は毎週日曜に技術系ではない記事を書いては挫折しています。これもどうにかなれ。 なんだか説教っぽくなって毎回ボツってます。 テストフレームワーク、Kiwi iPhoneのテストフレームワークは、色々あります。 Xcode標準のSenTestingKitは
TDDBC横浜の感想 - ゆとRubyist日記
TDDBC横浜にスタッフとして参加してきました。 TDD自体がはじめてなわけではないですが、まだまだ経験が浅いので、いい勉強になりました。 個人的に勉強になった点を中心にまとめます。ある程度TDDをやり始めた人がハマる点、この手があったかと思う点が中心になると思います。 なお、個人的には野球に詳しくなかったり、好きじゃなかったり、苦手だったりするので、別の例で書きます。 レッド、グリーン、『リファクタリング』 TDDというと、まずテストを書いてレッドになるのを確認し、実装をしてグリーンにし、その後リファクタリングをしてコードを整理します。これが、レッド、グリーン、リファクタリングです。 レッド、グリーンには気が向いていたのですが、その直後にリファクタリングをするということにはこれまで意識がまわっていませんでした。 (無意識に多少はやっていたような気もしますが。) イテレーションの中に、リフ
TDD の基礎体力と、TDD に対する想い - ぐるぐる～
TDD Advent Calendar 2011 の 4 日目の参加エントリです。 前半では、TDD を学ぶ前に身に付けておくといいと思う基礎体力について書きました。 後半は、まぁ、その。後悔はしていません。反論ウェルカム、議論しようぜ。 不安をテストに 「レッド - グリーン - リファクタリング」は、TDD の根っこの部分であり、これ自体が「どう TDD をやればいいか」を教えてくれるものではありません。 それに対して、「不安をテストに」というのは、「どう TDD をやればいいか」という指針を与えてくれる言葉です。 この言葉自体は、TDD Boot Camp で自分のものにできました。 不安については、テスト駆動開発入門では (言及されているものの) 自然に組み込まれていて、最初に読んだときには全然気づきませんでした。 しかし、TDDBC で id:t-wada (和田さん) に短くて
TDDを学ぶべき10の理由 #TddAdventJp - やさしいデスマーチ
かなり香ばしいタイトルですが、TDD Advent Calendar jp: 2011のエントリーとなります。前日の@bleisさんのエントリーの次になります。 はじめに TDD（テスト駆動開発）とは、「テストファーストを原則とし、テストが成功するようにプロダクションコードを書くというサイクルを繰り返す開発手法」です。XPのプラクティスの１つとして10年近く前に紹介され、ここ数年で再び１つのムーブメントとなっています。これは、TDD Boot CampがTDDへの敷居を下げ、体験する機会を提供した事も１つの大きな要因でしょう。 自分もTDDに魅せられたエンジニアの１人です。ぶっちゃけ、TDD信者とかTDD厨とか言われても可笑しくはありませんし、むしろ嬉しいくらいです。一方で、TDDを嫌う人もいるのも事実です。しかし、自分もTDDを銀の弾丸とは思っていませんし、適用しにくい領域もある事も理解
Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記
このエントリでは，Ruby on Rails （以下 Rails）の ActiveRecord モデルテストについて，1) どこの何をテストすればよいか，2) どのようにテストを書けばよいか，のガイドラインを示します．このガイドラインは Rails 公式のものではなく，id:passingloop が使っている私的なものです．疑問・質問・批判・間違いの指摘はページ下部のコメント欄までお願いします． はじめに Rails は TDD/BDD サポートが充実した Web アプリケーション開発フレームワークです．Rails で使える Test::Unit や RSpec などといったテスティングフレームワークの使い方に関する解説も豊富にあります．しかし，「どこをどうテストすればよいのか」についての解説は，「使い方」の解説と比較して少ないように思います．もっとも，テスト一般についてどう書くかはアプ
モックによるインターフェイスの発見 - Digital Romanticism
設計ツールとしてのモックの使い方について考える。 導入 先日、"Mock Roles, not Objects"の日本語版「ロールをモックせよ」を公開しました。この論文は2004年に書かれたもので、著者はSteve Freeman氏、Nat Pryce氏、Tim Mackinnon氏、Joe Walnes氏という豪華メンバーです。また、Steve Freeman氏とNat Pryce氏は『Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))』（いわゆるGOOS）の著者でもあり、"Mock Roles, not Object"で語られている思想はGOOSのベースになっているとも言えます。 今回は、この"Mock Roles, not Objects"（以下、MRnO
Curiosity PDF -
Alhemicar [Paulo Koeljo] on *FREE* shipping on qualifying offers. Alhemicar by Koeljo, Paulo and a great selection of related books, art and collectibles available now at : Alhemicar () by Paulo Koeljo and a great selection of similar New, Used and Collectible Books available now at great prices. Author: Samujas Kegis Country: Algeria Language: English […] Read More » On establishing universal pea
なぜ、個人のサービスなのにテストを書くのか。 « blog.udzura.jp
以下のエントリは、自分内ブレインストーミングの結果を書き起こしただけのモノなので、数年後どころか数ヶ月後でも意見が変わっているかもしれない。と言う前提で。 三つ、考えられる。 「未来の自分」が楽になる 自動テストコードは、その状態でのそのソフトウェアの挙動、仕様のスナップショットを撮る、と言う側面があり、それはドキュメントを各行為にも通じるが、「今書いている」自分以外の誰かがそのソフトウェアを変更したり、メンテナンスしたり、理解する際に役に立つ。人間はモノを忘れていく以上、「今書いている」自分以外、とは、当然未来の自分も含まれる。 実際、経験的にも、変更したらまずは rake spec を走らせて、エンバグしていないことを確認できるのは気持ちがすごく楽……。そのサービスを変えつづけていくつもりなら、是非テストを書こう。必ずいいことがある。 で、以下二つは、コードをgithubなどのソーシャ
Test Your API with Cucumber and json_spec | Collective Idea
At Collective Idea, we do a lot of work with RESTful JSON APIs. They can be a joy to build but a pain to test. We’re currently working on a project that’s all API all the time, so we developed some reusable Cucumber steps for testing. Now, we’ve abstracted all that goodness out into its own gem… json_spec. The Gem The json_spec gem is a collection of RSpec matchers and a collection of Cucumber ste
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
このページを見るには、ログインまたは登録してください
devlove2012-let-yor-test-drive-dev-more
