TDDをめぐる、最近の議論についての私見。 - bluebird
はじめに DHH氏のTDD is dead. Long live testing. (DHH)のエントリは、国内でもさまざまな議論を呼び起こしました。ですが、そのセンセーショナルな見出しの影響もあり、「(TDDと同一視した上での)ユニットテストは不要」などの、ミスリードされた論調も見られます。乗り遅れた感もあるのですが、前述のエントリに限らず、TDDについて最近考えていることをまとめたいと思います。 TDD＝テストファーストではない ケントベックの「テスト駆動開発入門」や、Uncle BobのTDD三原則の影響もあり、TDDでは、まずテストファーストするのだ、という印象をお持ちの方がいると感じてるのですが、いきなりテストファーストするというのは、教条主義なところがあり、現場に適用するのは敷居が高いのは確かです。 TDDを実践する上で大事なのは、テストによって開発が駆動されることです。すなわ
「実装をテストする」とは？ - bluebird
TDD界隈の議論で、「仕様のテスト」「実装のテスト」という話を聞くことがあります。 TDDのよくわからない言葉をどうやって説明するか悩んでいるという話 #SWTestAdvent — うさぎ組 明日からTDDをやってみよう！ - 部屋とアジャイルと私（仮称） 今日のTDD界隈で「仕様のテスト」「実装のテスト」という言い回しを一番よくしているのは私だと思うのですが、勉強会の場などでは話をすることはあるものの、こういう形で残してこなかったので、自分の考えをまとめたいと思います。 公開されているインターフェースの仕様を満たせるなら、API(「リファクタリング」で言う「公布済みインターフェース」)のエントリポイントの内側のクラス設計をどのように組み立てるかは、実装者の裁量に任されているはずです。 品質保証の観点からは、APIの仕様を満たせるテストケースを記述すれば、ソースコードに対してのある程度の
【再掲】TDD等を現場で実践していますか？ 自ら導入した場合にはその時の苦労を教えてください #tddadventjp - bluebird
このエントリーは、TDD Advent Calendar 2013の参加エントリーです。 前日のエントリーは、id:taczge さんのアサートファーストでテスト駆動開発 - Level.TRACEでした。 今回のエントリーは、2011年９月にザ・インタビューズに投稿したものの再掲載です。当時とは状況や考えが変わってきている部分もあるのですが、ザ・インタビューズが閉鎖するということもあり、史料的な位置づけとしてポストします。 Developer Testtingに関する読書会を主宰していながら扱っているのはレガシーコードばっかで歯がゆい思いをしていたのですが、今の部署に異動してからは周囲 の理解もあり、TDDで開発を進められています。あと今の所属がコストセンターなので、現場のプロジェクトでUnit Testを導入する際のCIの導入支援なんかもやっています。 直近のプロジェクトではレガシーコ
#tddbc の作り方( #TddAdventJp ) - bluebird
TDD Advent Calendar jp: 2011の先頭バッターであるこのエントリでは、先日開催したTDDBC横浜での経験をもとに、みなさんがTDDBCを開催することになった場合に、気をつけるといいことを書きたいと思います。 宣言 まずは「やります！」と宣言することからはじまります。TDDBCはやりたいと意思表明すれば誰でも開催することができますが、TDDBCのMLで宣言すると、開催経験のあるみなさんのサポートを受けることができてよいでしょう。 会場手配 会場を確保しないことには話がはじまりません。地域にもよりますが、首都圏の場合は半年以上前から公共施設の受付がはじまるので、早めのスタートが肝心です。また、多くの自治体では、公共施設の予約の時に使用者登録が必要となります。 会社の会議室を借りれる場合はスケジュールに余裕はでますが、稟議のフローは確実に進めてください。 基調講演の手配
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
