テスト駆動開発は戦略である - 偏見プログラマの語り！
本稿は、前回の記事 『テスト駆動開発について僕は誤解していた』 を踏まえた上で僕が TDD について思うことのまとめです。 どうも TDD は「あらゆる開発現場で適用できる」「大掛かりな仕掛けは不要である」「やった方が良いらしい」ことが見えてきました。ということは、世間は「TDD を実践するのが当たり前」になっているはずです。しかしどうもそうなっていないようです。何かがおかしい気がします。 Siri に聞いてみましたが教えてくれませんでした。 1. 手間がかかるから実践されていないのだろうか。 テストコードを書く手間はゼロではありません。お金儲けをしている以上、かける手間は少なければ少ないほど良いわけですよね。「手間がかかるからやらない」という意見はありえそうです。もしかして、これがネックになっているのでしょうか。 2. みんながやってないから実践されていないのだろうか。 前回の記事を書い
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
日本語版The RSpec Book - さかなチキンぱん。
ブログを移した為記事を移動しました。 新しいページへどうぞ
PHPでTDD&CIワークショップ、Jenkins + PHP の各種プラグインパート資料 - Yamashiro0217の日記
はじめに この資料は「PHPでTDD&CIワークショップ」 http://atnd.org/events/16626 で @yamashiro が発表するための資料だよ。 ワークショップ参加者じゃなくても記事読むだけで完結するようには書いてあるよ。 概要としては、Jenkins を使って PHP のウンコレガシーなコードをいかに綺麗にして行くかということを説明する。 自画自賛だけど PHPMD とか PHPCPD の使い方の説明の資料としてもそこそこイケてる資料になってると思いました。まる。 この記事に書かれてることは、割とTemplate for Jenkins Jobs for PHP Projectsとかぶってるけど、プラグインを絞ってあるのと、一個一個のプラグインについて解説、また実際にエラーが起きたときにどうすればいいのか書くよ。 Java と Jenkins のインストールとJ
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
プレゼンテーション ZEN 読了（要反復読書）
題名の通り読み終わりました。 amazonリンク で、読んでみて思ったこと。 プレゼンで使うスライドが全てを語るなら私がプレゼンする必要はない。 聴衆はスライドを見ることを楽しみにしてきているのか？ 文字ばかりのスライドってなにを見てほしいの？ 特に、システム系のカンファレンスのスライドは 視力検査の紙のようである。 スライドと講師の言ってることが＝である 睡眠導入剤 であると言える。 もちろん、そんな事は無い方は多いです。 先日のphpカンファレンスでphpUnit＋TDD＋Jenkins（CI）についてセッションされたyamashiro氏の スライドはセッションのustと併せて見ることで真価を発揮すると思う。 Ustream http://www.ustream.tv/recorded/17177077 PHPカンファレンス2011 PHPとテストとCIと私～愛するあなたのため～ Vi
[コラム] TDD のパターン: Assert First - TDD.NET
"Assert First" (Assert 文を最初に) は、 TDD するときのパターンのひとつとして Kent Beck の 「テスト駆動開発入門」 に出てきます。 最初のテストメソッドを書くときには、 これから実装する製品コードのメソッドのシグネチャ（名称、引数、型など）や置き場所、 それから肝心なテストケースとして与える刺激と期待される反応に、 製品コードを呼び出すために準備すべきことなどと、 たくさんの事柄を決断しなければなりません。 いっぺんに考えきれないようなら… そうです、 小分けにしてちょっとずつ進みましょう。 Assert 文を最初に書けば、 まず製品コードのメソッドのシグネチャを決断し、 最初のテストケースとしてふさわしい刺激と期待される反応を決めることができます。 それからおもむろに頭を切り替えて、 「この Assert 文をコンパイルして実行できるようにするに
![[コラム] TDD のパターン: Assert First - TDD.NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/fa41486a4ee0cc136d2d90da70bf607235e4e414/height=288;version=1;width=512/http%3A%2F%2Fwww.tdd-net.jp%2Fimages%2F2012%2F02%2F09%2F20120209_assertfirst01.png)
PHPUnit でよりよくテストを書くために
The document defines a fib function that recursively calculates Fibonacci numbers and prints the 10th Fibonacci number. It then defines some unit tests for a Calculator class that test the add method by asserting the expected result. Finally, it defines some unit tests for a User class that test validating a user object.Read less
テスト駆動JavaScript - それはBooks
タイトル テスト駆動JavaScript 著者 Christian Johansen (著), 長尾高弘 (翻訳) 出版社 アスキー・メディアワークス Amazonで購入する JavaScript のテストに関して書かれた、体系的な本がやっと出た！という感じにまとめられています。 本書では、JavaScript にスポットを当て、テストしやすい JavaScript のコードとはどんなものか、実際にテスト駆動で JavaScript のコードを書くにはどういう手順で進めていけばよいかについて書かれています。 本書は大まかに、次の4部に分けて解説されています。 第1部: テスト駆動開発 第2部: プログラマのためのJavaScript 第3部: JavaScriptテスト駆動開発の実際 第4部: テストのパターン 第1部では、一般的な自動テストやテスト駆動開発（TDD）の概念を説明しながら、
[書評]テスト駆動JavaScript - l4l
各所で良書だと評判の「テスト駆動JavaScript」を途中まで読みまして、自分もこれは良書だと思ったので書評的にブログエントリーを書いてみます。 table of contents 章立て この本を読むべき人 オススメな読み方 所感 まとめ １．章立て 第1部 テスト駆動開発 第 1章 自動テスト 第 2章 テスト駆動開発プロセス 第 3章 現役で使われているツール 第 4章 学ぶためのテスト 第2部 プログラマのためのJavaScript 第 5章 関数 第 6章 関数とクロージャの応用 第 7章 オブジェクトとプロトタイプの継承 第 8章 ECMAScript第５版 第 9章 控えめなJavaScript 第10章 機能検出 第3部 JavaScriptテスト駆動開発の実際 第11章 Observerパターン 第12章 ブラウザ間の違いの吸収：Ajax 第13章 AjaxとComet
RubyのRSpecでリボルバーを作ってロシアンルーレットしようよ! - hp12c
今までコードを書くとき 正直あまりまじめにテストをしてこなかったよ でもいつまでもそういう訳にはいかないだろうから 以下の記事を参考にしてRSpecをやってみたんだ RSpec の入門とその一歩先へ - t-wadaの日記 Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編) そうしたら次のようなことが分かったんだよ RSpecは設計図 RSpecはなんかたのしい でこの感覚をみんなと共有できればと思ったので RSpec入門者の僕がRSpecを使って ここで何か作ってみるよ さて 何を作ろうか.. 何か実用的で楽しいものがいいよね そうだ折角だからなかなか手に入らないものがいいね なかなか手に入らないものといったら.. もちろん輸入禁制品だよね! そんなわけで.. RubyのRSpecを使ってけん銃を作るよ
アジャイルにTDDしようとしてペアプロして失敗した話 - 水まんじゅう2
これはTDD Advent Calendarの18日目。 記事としては @mao_instantlife さんの TDDやってみてコメントが減った話 のあと、@cubeon さんの きっと方眼の理から逃れられないお前たちにも告げる！テストコードを手に入れるのだ！ の前となります。 最近、新しい開発手法の一貫としてTDDを採用しようとするプロジェクトが出始めている印象があります。 ただし、とりあえず取り入れてみたけれどもうまくいかなくて結局ウォーターフォール方式に逆戻りという例も多いのではないでしょうか。 以前、アジャイルにTDDをしようとしてペアプロして失敗したプロジェクトの話を聞いたことがあるので書こうと思います。 その時のプロジェクトでは数百人月前後の工数をかけてそれまであったレガシーシステムをJavaでリプレイスしようとしていたようです。 それなりの規模のプロジェクトに多いように、さ
CoffeeScript: a TDD example - DZone
CoffeeScript is a language building an abstraction over JavaScript (as the similar name suggests.) It is an abstraction over the syntax of JavaScript, not over its concepts: the language is still based on functions as objects which may bind to other objects, and prototypical inheritance. CoffeeScript favors the best practices of JavaScript by transforming abstractions you would have written anyway
TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組
@t_wada「TDDはスキルです。量は質に転化する」 TDD Advent Calendar2011の記事になります。 TDD Advent Calendar jp: 2011 : ATND 前：@irof テストと言うパートナー #TddAdventJp - 日々常々 次：@yuya_takeyama さんです。 はじめに これは僕の主観であって、間違いもあると思います。それは僕の勉強不足から生じるものです。 どちらかというと、これを読んだ方に「そこはちょっと認識が一般的じゃない」「そもそも違うよ」って突っ込んでもらうためのものです。 「TDDよくわからないので教えてください」っていう記事です。 TDDをはじめたい人、TDDに行き詰まっている人 TDDがどんなものかよくわからない人、とりあえずテストコードって書いているけど毎回つまずいて成長が実感出来ない人、現場に導入したいけど伝え方が
理想のJavaScript入門書 - L'eclat des jours(2011-12-08)
_ 理想のJavaScript入門書 アスキーの鈴木さんから、テスト駆動JavaScriptをいただいた。 これは、実に良い。おれが考える理想のJavaScript入門書に限りなく近い（というか、おれが書くより良いから上方向から近い）。 まず、これはTDDの本であり、JavaScriptの問題点は、それがRubyなどのスクリプト言語より、固いプログラミング言語（JavaとかCとか）に近い構文を持っているのが原因だと思うけど、どうしても変数とか関数名とか長く書きたくなるし（これは不思議な心理的な要求による）、言語が持つ予約語自体が長いし（functionだよ）、つまりいやでもタイプミスして死ぬ。 どうすれば良いかといえば、解決方法は2つしかない。プリプロセッサを用意して未定義変数とか利用していないかチェックするか、あるいはテストするかだ。前者よりも後者のほうがまあ有意義だ。というわけで、TD
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
TDDを学ぶべき10の理由 #TddAdventJp - やさしいデスマーチ
かなり香ばしいタイトルですが、TDD Advent Calendar jp: 2011のエントリーとなります。前日の@bleisさんのエントリーの次になります。 はじめに TDD（テスト駆動開発）とは、「テストファーストを原則とし、テストが成功するようにプロダクションコードを書くというサイクルを繰り返す開発手法」です。XPのプラクティスの１つとして10年近く前に紹介され、ここ数年で再び１つのムーブメントとなっています。これは、TDD Boot CampがTDDへの敷居を下げ、体験する機会を提供した事も１つの大きな要因でしょう。 自分もTDDに魅せられたエンジニアの１人です。ぶっちゃけ、TDD信者とかTDD厨とか言われても可笑しくはありませんし、むしろ嬉しいくらいです。一方で、TDDを嫌う人もいるのも事実です。しかし、自分もTDDを銀の弾丸とは思っていませんし、適用しにくい領域もある事も理解
TDD の基礎体力と、TDD に対する想い - ぐるぐる～
TDD Advent Calendar 2011 の 4 日目の参加エントリです。 前半では、TDD を学ぶ前に身に付けておくといいと思う基礎体力について書きました。 後半は、まぁ、その。後悔はしていません。反論ウェルカム、議論しようぜ。 不安をテストに 「レッド - グリーン - リファクタリング」は、TDD の根っこの部分であり、これ自体が「どう TDD をやればいいか」を教えてくれるものではありません。 それに対して、「不安をテストに」というのは、「どう TDD をやればいいか」という指針を与えてくれる言葉です。 この言葉自体は、TDD Boot Camp で自分のものにできました。 不安については、テスト駆動開発入門では (言及されているものの) 自然に組み込まれていて、最初に読んだときには全然気づきませんでした。 しかし、TDDBC で id:t-wada (和田さん) に短くて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【社内勉強会レポート】 TDDへの理解を深めるため、スライド資料「TDDを実践してわかった TDDつまづくあるあると自分なりの乗り越え方まとめ」を読む会を行いました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
TDD を自分の道具にしよう
