JJUG CCC 2014 fall 「私がTDD出来ないのはどう考えてもお前らが悪い!」~エンタープライズJava開発でのTDD適用の勘所~Hiroyuki Ohnaka
今日(2015-04-25)は福知山線の脱線事故から 10 年目の 4 月 25 日。つまり、まさーるさんこと石井勝さんが亡くなられてからも 10 年になる。 まさーるさんは、一言でいえば 1990 年代後半から 2000 年代前半の日本におけるオブジェクト指向プログラミング、自動テストとテスト駆動開発、そしてアジャイルソフトウェア開発の啓蒙において大きな役割を果たされた方だ。もしも 10 年前の福知山線に乗っていなければ、いまでも日本を代表するプログラマの一人だったのではないかと思う。 まさーるさんの残した足跡は、様々なところに見いだすことができる。 Java プログラマであれば、 Quick JUnit という Eclipse プラグインを使ったことがある方が多いのではないかと思う。 Quick JUnit はテストコードとテスト対象コードの間をショートカットで行き来できる便利なプラグ
RailsConf 2014 Is TDD dead? Is TDD dead? [Part II] Is TDD dead? [Part III] Is TDD dead? [Part IV] Is TDD dead? [Part V & VI] (40分くらいの Kent frozen がうける) TDD is dead. Long live testing. (DHH) 翻訳 2014-04-24 - やっとむでぽん 自動化したリグレッションテスティングが存在しないという残念な業界の現状 TDDには感謝しているが、設計の教義としてはとっくに使わなくなっている 間接的で過剰に複雑な構造を生みがちだ。「遅い」ものをすべて避けようとする 伝統的な意味でのユニットテストはほとんどしない。すべての依存関係をモックにし、何千というテストが数秒で終わるようなユニットテスト 我々は完全なシステムテス
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった (この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ)。 ユニットテスティングは
TDD/BDDにおける「振る舞い」の意味するところとは何なのか:いまさら聞けないTDD/BDD超入門(3)(1/3 ページ) 前回の「TDD/BDDの思想とテスティングフレームワークの関係を整理しよう」では、TDD/BDDについて、その思想と、それをサポートするテスティングフレームワークに分けて解説しました。その中で、TDD/BDDについては実際の熟練者の言葉を借り、テスティングフレームワークについては概要を触れて、その系譜をたどりました。 BDDはその名前に「Behavior」とありますが、「振る舞いとしてのテストコードを書く」とはどういうことなのでしょうか? 難しく考え過ぎる必要はありませんが、「それは振る舞いを書いていないよ」と指摘をする熟練者が何を考えているかを理解することはBDDを習熟していく中で重要な意味を持ってきます。 本記事では「振る舞い」という言葉がどのような意味で使われ
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
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね! で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
2013-12-02 テストのアプローチとそのメリット/デメリットのまとめを読んだ TDD 読んだ これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE を読んだ。 最後のまとめだけ引用するけど、これはTDDでは(というか和田さんが各所で)ずっと言われてることだし、それよりアプローチのメリット/デメリットについて何回でも読むべき。 * 良いユニットテストは Repeatable (繰り返し可能、再現可能) * テストダブルを使いこなす * 外部環境との界面にインターフェイスを作成し、テストダブルで置き換える * 良いユニットテストは独立 (Independent) していなければならない * 後始末を忘れずに行い、テストを独立させる * stat
テスト駆動開発の巨匠・和田卓人さんからの『現在時刻とロケールに依存するテスト』問題をPHPメンターズの後藤秀宣さんが解答してくださいました! この記事は、その後藤さんによる解答コードの公開と解説記事になります!! by CodeIQ運営事務局 PHPメンターズの後藤です。 和田卓人さん出題の『現在時刻とロケールに依存するテスト』問題をPHPを使ってオブジェクト指向のアプローチで解答してみました。 ※問題文については、和田卓人さんの解説記事を参照にしてください。 https://codeiq.jp/magazine/2013/11/1475/ 解答例は次の環境で作成しています。 PHP 5.5.4 PHPUnit 3.7 Composer サンプルコードのリポジトリをGitHubにて公開しています。コミットログなど合わせてご参照ください。(解説中にも各コミットへのリンクを貼ってあります) g
和田卓人さんによるテスト駆動開発問題解説の寄稿です! バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中! by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
This document discusses emergent design and test-driven development using PHP and PHPSpec. It emphasizes designing software through describing how objects interact to solve problems, focusing on messaging between objects. Simple design rules like removing duplication and complexity are recommended to make code more testable, modular, and change-friendly. Designing for delegation using mocks is pre
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
anti-pattern : there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea: Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results, and A refactored solution that is clearly documented, proven in actual p
年に一度行われるアジャイル開発のイベント「Agile Japan」が今年も開催されました。今年の基調講演は、アジャイル開発の中で品質の重要性をあらためて位置づける目的で、James Gernning氏が「“Demand Technical Excellence”アジャイルにおける技術と品質の重要性」という題で行っています。 (本記事は「アジャイル開発において、技術と品質の重要性は不可欠だ(前編)。Agile Japan 2013」の続きです) 品質を作り込むプロセス コンピュータサイエンティストとして有名なEdsger Dijkstraは、信頼性の高いソフトウェアが必要であれば、最初からバグを避ける方法を探さなければならないことに気づくだろう。と言っています。 つまり、バグを作り込まない、品質を作り込むプロセスにすることで、大事な時間をデバッグに使われないようにするのです。 テストドリブン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く