単にテストファーストの進化系的に語られている(歴史的には進化系に違いないけど)。 でも、仕様なり要求がなり入力がないとテストコードは書けないでしょ。 ドメインモデルとどうやって結びつけるの。 ドメインモデルがこけたらこけちゃうでしょ。 ドメインモデルもテスト(not レビュー)しないとだめなんだよ。 XPはPだけどTDDはDなんだよ。 いまのTDDはTDPじゃないか。 OOP→OOD→OOAと発展?したように TDP→TDD→TDAってまどろっこしい進化をさせないといけないのかな。 そういえば、アスペクト指向がそんな感じでしたね。 テストファースト本でW字モデルまでだして、このあたりを述べたけど、もう一度整理しないとダメだな。要件定義工程でレビューしているくせに、いまだに要件定義工程ではテストできないっていっているし。標準じゃないんだから、個人なりコミュニティの定義に拘束されることないと思
テスト駆動開発が嫌いだ。 ただし、ここでの「テスト駆動開発」は日本で今TDDと呼ばれてる多義的なものじゃなく、「テスト駆動開発入門」にかかれている「テスト駆動開発」。 もっと正確にいうと「テスト駆動開発入門」がミスリーディングをわざと誘ってて有害で嫌い。 テストは、プログラムが正しく動くことは検証できるけど、プログラムが正しいことは検証できない。そのようなテストに設計を依存してしまうと、正しく動くプログラムは作れるけど正しいプログラムは作れない。 設計も含めてテストによって駆動しましょうという「テスト駆動開発入門」のやり方では正しいプログラムが作れない。プログラムの正しさを別のやり方で担保しつつ、そちらを中心に開発を駆動して、あくまでも開発作業だけをテストで駆動するという考え方のほうが、正しいプログラムに近づける。 そして、TDDをいまがんばってる人たちも、それは当たり前にわかってると思う
8. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 3か月前の@remore 9. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 後に現実を知ることになります
BDDについて自分なりにまとめてみた Published on 2011-07-02 Updated on 2011-07-02 BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振
「TDDの本ってあまり売れないんだそうですよ。」と言う発言から思ったことをつぶやたら思いがけない広がりになったので、まとめてみました。(未完)
xUnit Test Patterns: Refactoring Test Code 良さを伝えるのは結構難しい。勉強会も開かれているので広く読まれている事は間違いない。ただ読むのはしんどい。「どこから読み始めても分かるように」という筆者のありがたい配慮により、とにかく冗長な構成。全く同じ文章をコピペしたのではないか？という箇所もちらほら。おかげで833ページ。 読む価値はある。筆者は間違いなくテストを書く事と真剣に向き合っている。本書でしか読めないパターンも多い。Mock Object、Stub、Test Spy の違い。Slow Test に立ち向かうための Fixture 。種々の Result Verification 手法などお腹いっぱいの内容。 本書が出たのは 2007年5月。やっと 2007年のテスト事情まで追いついた。次は2009年末に出たGrowing Object-Or
結論を最初に書くと、 テストコードを書くだけではダメで、デイリービルドなりCIしないと意味ないんじゃないっすか？という事です。 最近Hudsonを使っていてすごいいいなぁ、と思うのがこの画面。 「リグレッション」という表現はすごい的を射ているなぁ、と思います。以前は「失敗」となっていたと記憶しています。 なんで的を射ているかと思ったかと言うと、テストコードって回帰テストの中で動かされると、その結果は「成功」と「失敗」だけではありませんよね。仕様変更による影響がテストコードので、テストコードが失敗すると言う事もある訳で。確かid:hyoshiokさんのブログだったかで拝見したかなんかだったんですが、Oracleでは毎朝デベロッパが出社すると、QA担当の人から失敗した回帰テストが回覧し、デベロッパに「これは障害なのか、仕様変更による影響なのか」を判断してもらった、と言う話を目にしました。テスト
twitter で TDDBC Hokuriku (2010) のレガシーコード改善を Coding Dojo で行った際の Ruby チームは比較的うまくいってたけど、あれって○○な流れだっけ的な話をしているうちに気になってることをまとめておこうと思い立ったので、できるだけ書き出してみる。 何かのきっかけになれば嬉しい。 素材（レガシーコード）のポイントまず動くこと触ったことがあること1ある程度でいいので機能別に書かれていること オブジェクト指向であるとなお良い（使える技が増える）小規模であること ただし完全に単機能だと余地が少ないのでテストを足しにくい外部 API 依存しまくりの場合は単なるレガシーコード改善とはまた別なテクニックの習得に繋がってよいかも自動実行できるテストがないこと :-)1 については「えっ」て思うかもしれないけど、放置してるものは依存ライブラリの関係や、そもそも動
JavaScript のテスティングフレームワーク QUnit から TAP 出力するための仕組みを作成し、さらに CommonJS 環境下でも動くようにしてみましたので、 github で公開します。ライセンスは QUnit に合わせて MIT と GPLv2 のデュアルライセンスです。 http://github.com/twada/qunit-tap これは何? 平たく言うと、主に画面非依存の JavaScript コードやサーバサイドで動かす JavaScript コードに対してコマンドラインからユニットテストを行うための仕組みです。 js のユニットテストというとブラウザ上で動かすものが一般的ですが、 DOM に依存しないロジックや抽象的なモジュールのテストはできればコマンドライン上で高速に実行させ、即座にフィードバックを得たいものです。 (更新) ヘッドレスブラウザ Phant
感想を一言で「実装がゲームになった！」 なにを言ってるか判らないときは続きをどうぞ TDDを勧めてる人と知り合ってすっごい経って最近飲み会以外であってない気がする そんなある日の事(そんな事よりTDD勧めてるのって双子のどっちだっけ・・・) ふとそういえばTDDってあったなぁとふと思い出したので、本を探してみた 無い・・・あれ？あの人雑誌記事ばっかり書いてて本書いて無いんだ〜って思ったのでTDDの翻訳本の方を買った 平日にせっせと読んだので、ちっちゃいユーティリティー的なコンポーネントを作るのに突然やってみた。 テスト書いて〜インタフェース書いて〜ダミー実装書いて〜レッドバーダして〜実装書いて〜グリーンバー ってのを数分単位で繰り返す・・・ あっという間に時間が１５分ほど経った。 んでふと実装コードの量を見てみた。こんな量なら5分でテスト無しならかけるぞ！！ それからまた３０分ほど繰り返し
はじめに 単体テストとは、システムの構成要素であるクラスやメソッド単位での動作を確認する作業のことを言います。 Webシステムは基本的に不特定多数に公開するものであり、公開前にはきちんとテストを行っておくことが重要です。 PHPにはテストツールとしてPHPUnitという単体テストのツールがあり、PHPUnitを利用するとクラス内のメソッドに対してテスト用のクラスを自動で生成し、効率よくテストすることができます。 PHPUnitを利用して単体テストする場合のプロセスは テスト対象となるクラス、PHPプログラムの作成 1.で作成したクラスからPHPUnit内のクラスを用いてテスト用のクラスを作成 2.で作成したテスト用のクラスに目的に応じてテストメソッドの実体を記述 テスト実行、結果の確認 となります。 本記事では、本連載第4回『GPS携帯を使った口コミサイト構築』の逆ジオコーディング処理をテ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
ケント・ベック師の著書で、TDDの教科書「テスト駆動開発入門」の、「Part1 Money オブジェクトの例」を写経して、TDDを「実践」し、これまで学習した「パターン」「プラクティス」を理解し、定着させます。目次テスト駆動開発・実践編01・黄金の回転（「第1章 複数通貨のMoney」より）テスト駆動開発・実践編02・テストファースト（「第2章 オブジェクトの退化」より）テスト駆動開発・実践編03・（「第3章 すべてに対する等価性」より）テスト駆動開発・実践編04・（「第4章 プライベート化」より）テスト駆動開発・実践編05・（「第5章 『フランク』に話す」より）テスト駆動開発・実践編06・（「第6章 再度、すべてに対する等価性」より）テスト駆動開発・実践編07・（「第7章 りんごとみかん」より）テスト駆動開発・実践編08・（「第8章 オブジェクトの生成」より）テスト駆動開発・実践編09・
Q：大きすぎるテストケースをどのように動作させるのかA：大きなテストケースで失敗する部分を抜き出して、小さなテストケースを作成する。小さなテストケースを動作させてから、大きなテストケースを再度導入する。どうして？成功を続けるためには「レッド」「グリーン」「リファクタリング」のリズムがとても重要です。しかし、動作させるのに複数の変更を必要とするテスト、つまり比較的大きなテストケースを作成してしまうと、このリズムが失われる場合があります。開発者はレッドバーが10分も続くと不安になります。どうすれば？大きすぎるテストを実行して失敗した場合、まずテストが失敗する問題の部分を抜き出します。そこだけの小さなテストケースを作成して、動作させてから大きな問題に再度取り組みます。一般論として、AとBとCの3つの事を一度にやろうとするのは失敗の元ですが、AとBとCを各個撃破してから全体をやっつけるのは容易です
Q：疲れたり、行き詰ったりした時はどうすべきか。A：休憩を取る。どうして？疲れたら、疲れていることに気付かなくなり、そのまま仕事を続け、ますます疲れてしまいます。その疲労は判断にネガティブに影響し、判断も疲労にネガティブに影響します。どういうこと？飲み物をとり、散歩し、居眠りをします。そして、手を洗い、直前の決定や記述した内容への感情を洗い流します。これだけ距離を置けば、欠陥のある考えから脱却できます。立ち上がるだけで「引数を逆にして試していなかった」と気付くこともあります。休憩は数分でも効果はあります。アイデアは逃げません。どうすれば？疲労の悪循環から抜け出すために、様々なレベルの休憩を取ります。数時間単位の休憩 キーボードの側に水の入ったボトルを置いておきます。そうすれば、定期的な休憩を生理的に取りたくなります。1日単位の休憩 定時後の約束は、睡眠不足で進捗が進まない場合に作業を止める
Q：欠陥が報告された時に最初にすべきことは何か。A：失敗する最小のテストを作成し、実行した後に修正する。どうして？テストを最初から完璧にするのはほぼ不可能です。最初のコーディング時に作成していたテストから漏れているパターンは、欠陥により発見される場合があります。どうすれば？欠陥が報告された場合、すぐに修正から始めるのは良くない習慣です。まず漏れていたテストパターンを追加します。レッドバーから開始し、その上で欠陥を修正します。回帰テストは様々なレベルでのフィードバックを促してくれます。アプリケーションに対する回帰テストがあると、ユーザは間違っていることや期待していることに関して、具体的に話すことができます。小規模な回帰テストはテストを改善する方法です。欠陥で、不自然に大きな負の数字が報告されたとすると、テストリスト作成時に整数のロールオーバーに関するテストが必要だったということを示唆していま
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
東大総長の平成30年度卒業式告辞で見田宗介の名前を知り「まなざしの地獄」とともに読んだ。本書は「脱高度成長期」をむかえた現代社会がどこに向かうのかを正面切ってとりあげている。 指数関数的な経済成長というのがありえないということを我々はすでに知っている。地球の資源は有限だし、人口増加も頭打ちになっている。しかしながら、我々の精神性においてはどこかに経済成長を望んでいるし、暗黙の仮定として、それを前提としている空気もある。 見田宗介はロジスティック曲線とよぶS字型の曲線を例に現代社会の行く末を占う。(8ページ) 1970年代のローマクラブの「成長の限界」を持ち出すまでもなく、成長はどこかに限界がある。それをロジスティック曲線が端的に表している。 「貨幣経済という人間の最大の発明の一つ」（132ページ）で欲望はどこに向かうのだろうか？ 「生活のための物質的な条件が確保されれば、それ以上の経済など
ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
