TDDをめぐる、最近の議論についての私見。 - bluebird
はじめに DHH氏のTDD is dead. Long live testing. (DHH)のエントリは、国内でもさまざまな議論を呼び起こしました。ですが、そのセンセーショナルな見出しの影響もあり、「(TDDと同一視した上での)ユニットテストは不要」などの、ミスリードされた論調も見られます。乗り遅れた感もあるのですが、前述のエントリに限らず、TDDについて最近考えていることをまとめたいと思います。 TDD＝テストファーストではない ケントベックの「テスト駆動開発入門」や、Uncle BobのTDD三原則の影響もあり、TDDでは、まずテストファーストするのだ、という印象をお持ちの方がいると感じてるのですが、いきなりテストファーストするというのは、教条主義なところがあり、現場に適用するのは敷居が高いのは確かです。 TDDを実践する上で大事なのは、テストによって開発が駆動されることです。すなわ
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
TDL
Learn coding in pragmatic way Read textbooks? Did tutorials? Here is the next step for you. Create new account (it's free) Get coding exercise Download a test-bundled exercise via Git. Workout on your machine Produce code to pass the test. Submit and get feedbacks Submit your code. Learn by reading Read other users' code.
プロジェクトにおけるTDDの重要度の話
Satoshⅰ Nakagawa @Psychs 成功したサービスを作り始めた時に、どのくらいの割合のプロジェクトが最初から TDD とかやってるのか気になる。 2012-08-09 13:33:33
PHPのテスティングフレームワークとBDD（ビヘイビア駆動開発）について調べた。 | 48JIGEN *Reloaded*
PHPのテスティングフレームワークとBDD（ビヘイビア駆動開発）について調べた。 2011/04/03 2月に北海道は定山渓温泉で行われた1泊2日のLTハッカソンLOCAL DEVELOPER DAY ’11 /Winter(以下LDD11Winter)に参加してきて気力も体力もすっかり充実してきた@remoreです。 LT大会楽しかったな。高橋さん（高橋メソッドのお方）とこいわさんのプレゼンを生で見れたのが特に勉強になりました。LOCALの皆さん、期間中は大変お世話になりありがとうございました。 充実してきているPHPのテスティングフレームワーク で、今日の記事を書こうと思ったきっかけがLDD11Winterでこんな話を小耳に挟んだことだったのでした。 ”Rubyではテスト駆動開発（TDD）の環境が充実していて、テストのことを学びたい人も集まってきているよ” 帰って調べてみると、確かにR
iOS開発における現実的なCI環境 - jarinosuke blog
継続的インテグレーション 最近では iOS アプリでも単体テストを使った継続的インテグレーションが注目されています。 iOS 開発の単体テストについては、このブログでも取り扱いました。 Xcode 4 からはじめる Unit Testing GHUnitとOCMockでUnit Test効率化 一般的な CI 環境についての説明は、以下の本から抜粋するとこんな感じです。 Jenkins 作者: John Ferguson Smart,Sky株式会社玉川竜司出版社/メーカー: オライリージャパン発売日: 2012/02/22メディア: 大型本購入: 12人 クリック: 299回この商品を含むブログ (26件) を見る デプロイメントに至るまでの開発プロセスをスムーズにし、バグの検出とフィックスを素早く行えるようにし…(略) では iOS 開発における現実的な CI 環境を考えていきましょう。
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
例えば, Singleton を避ける | Born Too Late
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
C言語でもレガシーでも、TDD をやってやれないことはない(レガシーコード改善成分90%、TDD成分10%) - yujioramaの日記
id:goyoki さんの次になるTDD Advent Calendar jp: 2011の9日目です。 まったく自重しない素敵エントリが続いているので、ここらで息抜きをしましょう。 TDD についての理論、情緒、実践についてはすでに語られてしまったので、現場で使われた話を書きたいと思います。 前提 このお話は フィクション です。 現実によく似た光景を見たり聞いたりしたとしても、それは幻想です。幻想のはずです。幻想ということにしてくださいお願いします。 はじめに そこには C 言語のシステムがありました。 規模にして数万行の中規模なシステム。 24時間365日動き続けることが要求されるもので、僕の仕事は、このシステムの中枢部をうまいこと改修することでした。 テストコードはあるものの、設計に大きな変更が入る前のプロダクトコードが対象となっていて、ユーティリティ関数以外のテストは全滅という、
TDDのはじめかた #TddAdventJp - 千里霧中
本エントリはTDD Advent Calendar jp: 2011の12/8の担当分の記事で、id:t-wadaさんの「右手に感情、左手に数値 - カバレッジを味方にしよう - t-wadaの日記」に続くものです。 はじめに TDDはシンプルな原則に則った手法ですが、とっつきの悪さもしばしば持たれがちです。また一連のTDD Advent Calendarで起こった議論や会話の中でも、TDDの始め方はどうすれば良いかという話が散見されましたので、自分の担当枠では「TDDのはじめかた」についてまとめたいと思います。なお紹介するのはあくまで数ある入門方法のうちの１つです。たぶん他にも色々な良い入門方法があると思います。 全体像 紹介する入門方法は以下のようなステップバイステップの構造となります。 いつでも軽快に使えるユニットテスト環境を構築する 必要と感じたらすぐテストを活用する テスト並行を
PHPUnit の実行を自動化する 3 つの方法 | Born Too Late
皆さん, ユニットテスト書いてますか. TDD (テスト駆動開発) によるプログラミングは本当に楽しいものですが, コマンドをいちいち手動で実行するのは面倒ですよね. テストを自動化しているんだから, その実行も自動化したいですよね. この記事では, 私が仕事や趣味で使っている PHPUnit を例に, テストの実行の自動化について紹介します. PHPUnit の, としてはいますが, 他の言語で使えるテクニックもあります. なお, ここでの自動化は開発しながらの自動実行のことで, CI (継続的インテグレーション) の話は出てきません. その前に... 私の開発時のターミナルは以下のようになっています. [caption id="attachment_1298" align="alignnone" width="300" caption="開発時のターミナル"][/caption] GN
PHPUnitの環境をつくろう for PHPer #tddbc in Tokyo | Act as Professional
お手持ちの環境で、下記のように表示される方は問題ありません。安心して、TDD Boot Camp in Tokyoにお越しください。 $ phpunit --version PHPUnit 3.5.14 by Sebastian Bergmann.さて、そうではない方に向けての記事です。PHPUnitを自分の環境に構築しましょう。 PHPUnitはJUnitを参考にしてつくられた、PHP向けのxUnitツールです。PHPのテスティングフレームワークでは鉄板のツールです。（あんまり僕は使う機会がないのだけれど） 環境以下の環境が必要です PHP 5.2.7 以上 インストール方法pear channel-discover pear.phpunit.de pear channel-discover components.ez.no pear channel-discover pear.symf
既存システムでTDDするのが難しい理由 - くろまほうさいきょうでんせつ
TDDしたい、CIしたいと思ってもなかなか導入できない。何でだろう？ PHP製WebアプリケーションでのTDDを学び始めた現時点の気持ちまとめ。 Seleniumを使うような高いレイヤーのテスト どんなテストを書けばいいのかわからない 例えばDBから商品情報取ってページ生成する場合。 商品カテゴリごとに異なる趣きのページを作るのでそれぞれにviewのテストを書いたとする 各ページ内の商品詳細URLにパラメータが追加されることになった URL生成は共通のモデルで行っている 修正は一ヶ所で簡単なもの だったとしてもviewのテストはそうは行かない。 先に用意したテストケースを全部書き直さなきゃならない。 小さな変更にかかるコストが大きくなる 単純に時間がかかるというより めんどくさくなる → どうせやらなくなる という思い。 コントローラーとか中間くらいの層のテスト viewよりは下、ユニット
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
CakePHPのテストに触れてみる。 - たかふーのブログ
前回、CakePHPを使ってみることをしました。 今回はテストについて見てみます。 モデルのリレーションについて掘り下げた方が良いような気もしたのですが、プログラムを書くだけでテストを考慮しないなんてモモタロスのいない電王みたいなものなので、テストを取り上げます。 CakePHP 1.2 には、テストのための包括的なフレームワークが組み込まれています。このフレームワークは、PHP 向けの SimpleTest フレームワークを拡張したものです。この章では、テスト、それの構築および実行についての準備をどのようにするかを説明します。 no title 1.3のマニュアルの筈なのにCakePHP 1.2とか書いてあるのが気になりますが、それはさておき(というか、このセクションは1.2から変化ないようですね)CakePHPではSimpleTestという既成のテスティングフレームワーク的な何かが使わ
CakePHP でテスト駆動開発 - elm200 の日記(旧はてなダイアリー)
参考にした情報。 CakePHP1.2 に SimpleTest をインストール CakePHP1.2 SimpleTest でテストケースを作成する が良エントリ。 CakePHP では SimpleTest というテストモジュールを使うらしい。ここからダウンロードして解凍し、app/vendors か vendors に配置する。SimpleTest はテスト結果をウェブベースで表示するようである。app/webroot/test.php がテスト実行のエントリポイントである。 http://(サーバ名)/(CakePHP アプリケーションへのパス)/test.php という感じの URL にブラウザからアクセスする。 テストの書き方。たとえば、post.php というモデルがある場合、app/test/cases/models/post.test.php というテスト用のファイルを作
CakePHPでフィクスチャに惑わされずにテストを書く方法
前回挙げたチュートリアルはやってみましたか？ 快適なテストライフを送ってますか？ テストケースをたくさん書いていると気づくのは、フィクスチャがメンテナンスの邪魔をするということ。 フィクスチャに初期データを定義すると、それを気にしながらテストケースを作ることになります。 これがとても面倒くさいんです。 これを解消すべく、今日はモックを使ったテストケースの書き方を紹介します。 モックとは SimpleTestのモックで参考になるのは、以下の書籍です。 Webアプリケーションテスト手法 著者: 水野 貴明 (著), 石井 勇一 (著), 新藤 愛大 (著), 岸田 健一郎 (著), 荻野 淳也 (著), 安井 力 (著), 田中 慎司 (著) 出版社: 毎日コミュニケーションズ 発売日: 2008/7/25 この書籍のp154にモックについて以下のように書いてあります。 モックを使うと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイル開発とTDDを半年間実践してみた顛末と、これから
WEB MEMO: cakephp2.0でのテストについて
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
