Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最初に テスト駆動開発（以後TDD）の存在を知って、自分で取り入れてみてから、自分の開発は良くなったと思っています。 TDDを人におすすめしよう！ と思って本を読んだり色々と調べていたりするうちに、 TDDは死んだ とか、テスト全部書かなくても...と言われていることを知りました。 それでも自分はTDDで開発するのが好きだし、自分には合っていると思うので、自分がTDDを愛する理由を書いてみたのがこの記事です。 若干ポエム寄りになっているかもしれませんが、ご容赦いただけると幸いです。 前提としていること TDDの基本的な流れとして、タスク
■ AgileSamurai BaseCamp の TDD セッションで講演してきた @t_wada さんから、AgileSamurai BaseCamp の TDD セッションで技術的負債や組織としての取り組みについて話して欲しいという依頼がきたので、社内に公開されているあんちぽくんの資料やブログからよくまとまっている内容を切り出して、僕の考えるところを中心に講演とパネルディスカッションしてきた。 社内でも DX! DX! とか、開発者のおもしろさ、みたいのを担当しているんで、その辺をもう少し噛み砕いて話したつもり。他の講演者が純粋にTDDをどうやって組織に広げるか、チームのTDD状況というような話だったのに、一人だけハードコアな話になってしまった。ばたり。
TDDをめぐる、最近の議論についての私見。 はじめに DHH氏のTDD is dead. Long live testing. (DHH)のエントリは、国内でもさまざまな議論を呼び起こしました。ですが、そのセンセーショナルな見出しの影響もあり、「(TDDと同一視した上での)ユニットテストは不要」などの、ミスリードされた論調も見られます。乗り遅れた感もあるのですが、前述のエントリに限らず、TDDについて最近考えていることをまとめたいと思います。 TDD＝テストファーストではない ケントベックの「テスト駆動開発入門」や、Uncle BobのTDD三原則の影響もあり、TDDでは、まずテストファーストするのだ、という印象をお持ちの方がいると感じてるのですが、いきなりテストファーストするというのは、教条主義なところがあり、現場に適用するのは敷居が高いのは確かです。 TDDを実践する上で大事なの
README.md Steve Freeman氏とのペアプロ雑感 http://tddbc.doorkeeper.jp TDD Boot Camp 2013-07 -- TDDBC で、偶然にもロンドンから来日していたSteve Freeman氏を招くことができた。ちなみに本当に偶然の来日で、その日の夕方にご家族と隅田川の花火を見る予定だったらしい。貴重な時間である。 20分ほど講演していただき、さらに参加者と一緒にペアプロ課題に挑戦してもらった。しかもペアプロでっていう貴重な体験をさせてもらったので、そのことについてまとめたい。 Steve Freeman氏は書籍 "Growing Object-Oriented Software, Guided by Tests" （邦訳「実戦テスト駆動開発」）の共著者の一人で、Javaのモックフレームワーク "JMock"の開発者の一人。当然、自動販
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
去る8月にアメリカ・テキサス州ダラスで開催された Agile 2012 にて James Grenning さんにインタビューを実施させていただきました。James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『Test Driven Development for Embedded C』[1] の著者、アジャイルソフトウェア開発宣言の著者17名の1人、そしてアジャイルな見積り手法「プランニングポーカー」[2] の考案者でもあります。 インタビューでは、日本の「 Test Driven Development for Embedded C読書会 」参加メンバーから挙がった以下の話題についての質問を順次尋ねる形で進めました。 ・ 組み込みソフトウェアに対するアジャイル開発やTDDの導入 ・ モデリングやアーキテクチャ設計と TDD の関係 ・
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
Test, 雑感, iPad, iPhone, Objective-Cテストを書く事でおこるいい事は、いろんなところで解説されているので、iOS開発に限ったもので、わりと僕の中でキたViewControllerについて。ViewContollerがデータを所持しているケーステストをしていく上で課題になるアプリケーションテスト。iOSアプリケーションなので必ずビューが存在するわけですが、こいつを操作するViewControllerが非常に厄介な存在になってくる。少なくともApple公式のドキュメントのような書き方をすると、すぐに破綻する。例えば、こういうコードをよく書くと思いますが、この時に描画されるデータが正しいかをテストする為だけに複雑で手間のかかるアプリケーションテストをする必要があるでしょうか。 - (UITableViewCell *)tableView:(UITableView
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Joel on Softwareに面白そうな記事が載っていた。 とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。 さて、冒頭で Joel 氏はこう言っている。 Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
