第15回 追い込まれたときのテスト | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326039 担当からの発言「追い込まれている」というのが理由で、テストをさぼることはありますか？ 私の場合は、テストをサボることはあります、いや、ありました。もう少し正確に言うと、テストを書くのをさぼるというより、テストを「先に」書くことをサボった、そういうことはありました。 以前、もうリリース間近のプロジェクトで、お客様が機能が欲しいことがわかっていて、さらに直近で仕様変更もありました。その結果、赤くなってしまった（テストが失敗する）プログラムがいくつか出てしまったり、新たにテストを書いてから開発しなければならないコードがあるというとき、これはもう大きいテストを通すまでに、小さいテストを積み上げていく余裕はないなと判断したことがあります。 そのような場合に、ちょっと冒険的に、小さいテストを少なめに、要する
第19回 チーム開発での規約・規律 | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326598 宮澤さんの発言チームでTDDを行うときは規約を決めると思うんですけど、その点について教えてください。 チームでの開発では、複数人で開発を行う際に、テストの書き方を個々人好きにやっていいというのではなく、書き方の取り決めや指針みたいなものを出すかどうかという話ですね。 大きいプロジェクトの場合 プロジェクトの性質にもよると思いますが、指針を出すプロジェクトは多いのではないかと思います。「ユニットテストはこういった視点でやります」とか、「このようなところは重点的にテストしてください」などというテスト指針は、大きいプロジェクトになればなるほど重要になってくると思うんですね。 また大規模プロジェクトの場合には、そのプロジェクト用のテストフレームワークを作ることもあると思います。JUnitやS2Uni
第16回 プログラミング言語とTDDは、どちらを先にマスターすべきか？ | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326111 クロコさんの発言TDDの学習を始めるときに、プログラミング言語はマスターしておかないと始められないのですか？ この疑問に関しては、みなさんいろいろ意見があると思います。 まず、TDDをマスターしていて言語をマスターしていないのか、言語もTDDもマスターしてしていないのかで全然状況は違うと思います。 私自身はTDDをある程度マスターしていると考えていますが、私はプログラミング言語をマスターするために、TDDをやってみることがあります。ちょっとピントのずれた回答かもしれないんですけれど。 全然経験がないプログラミング言語があるときに、どういうやり方をしていくかというと、どんな言語にも、だいたいテストコードのサンプルとテスティングフレームワークがあるわけですね、たとえばSmallTalkだったらSUn
第18回 公布済みインタフェースのリファクタリング | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326506 家永さんの発言リファクタリングの話のときに、publishedインタフェース、publicインタフェースというキーワードが出てきましたが、その点についてもう一度整理してください。 publishedインタフェース、publicインタフェースという言葉が出てきました。 まず、publicというのはJavaのpublicだと思ってかまいません。プログラムのどこからでもアクセスできる可視性を持っているインタフェースをpublicインタフェースといいます。Javaで言えばインタフェースは全部publicですね。 それに対してpublishedインタフェースというのは、そういったpublicインタフェースの中のさらに一部分のことを指します。publishedというのは「公布済み」とか、「公開済み」と訳さ
第17回 リファクタリングをどこまでするか、いつやめるか | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326406 担当からの発言みなさんが、リファクタリングをどこまでするかとか、やめどきとかについて聞かせてください。 「重複は悪」「DRY（Don't repeat yourself）」 リファクタリングをどこまでするかというのは、実はすごく難しい質問なんですけども、端的に一言で「いつまで」と言うならば、「重複がなくなるまで」ということが一つの指標としてありますね。重複というのは、コードの重複です。まったく同じコードが二箇所以上に存在している状態です。 「重複は悪」もしくは「DRY（Don't repeat yourself）」という言葉があります。たとえばあるコードが書かれています。そのコードをコピーして、もう一つ機能を作りましたというときには、ほぼ同じコードが二ヵ所に書かれていることになります。 ある
第13回 私のTDDへの目覚め | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325802 前回までで、講義でお話しようと思っていたトピックは一区切り付きました。 今回からは、今日お集まりいただいてる方と、フリースタイルの質疑応答のような形でこの場で議論していきたいと思っています。 家永さんの発言TDDを最初は疑いの目で見ていたと思うんですが、和田さんがTDDに目覚めたタイミング、「これは！」「こりゃいいぞ！」と変わったタイミングについて知りたいです。 実際にまず、連載第6回でお見せした『テスト駆動開発入門』（Kent Beck 著／テクノロジックアート 訳／長瀬 嘉秀 監訳／ピアソン・エデュケーション 刊）を写経しました。写経した結果、テスト駆動開発がちょっとわかったと思いました。 私自身はもともとテスト駆動開発する前まではあんまりテストを書かないタイプのプログラマだったのです
第12回 モックオブジェクト技法：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325718 家永さんのコメント そうですね。 今「モックテスト」という言葉が出てきました。モックテスト、モックオブジェクトという技法は、『WEB+DB PRESS Vol.35』の特集1「実演！ テスト駆動開発」でも少し説明しましたが、この場で詳しく説明しましょう。 モックオブジェクト技法とは 「モックオブジェクト」「モックテスト」とは、ニセモノのオブジェクト（モックオブジェクト）をテストに使う技法です。本物のコードや本物のクラスではなく、テスト用の偽者のオブジェクトを作成し、テストを書きやすく、実行しやすくします。 詳しくは後述しますが、具体的には、テスト対象である本物のクラスと、それと協調動作するオブジェクトの偽物を使います。偽者オブジェクトは、テストの中で、テストの内容に即した動きをします。 メリ
第10回 テストの最小単位は不安 | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2316665 クロコさんからの質問 なるほど。連載第5回でも、「写経をやってみた、リズムもわかってきた。でもいざ自分でやろうとすると、最初はどういうテスト書こうかとか、どういう単位でテストを書けばいいのかとかで詰まってしまう」という質問をいただきましたね。 私は実は、明確にこういう単位でテストを書くべしという決まりはないと思っています。 不安をテストで表現する では、私がどういうときに小さいテストを書いているかというと、私は「不安」を最小単位の基準としています。不安を手がかりにしてテストを書きます。 私たちプログラマの手を止めるものは何でしょうか。私は「不安」だと思っています。「もしかしたら」という感情ですね。「もしかしたら、自分の書いているコードは間違っているかもしれない」「もしかしたら、ライブラリ
第11回 テストの資産価値 | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325613 宮澤さんからの質問 そうですね。またよい質問をいただきました。「テストの資産価値」という話をこれからしたいと思います。 小さいテストがすべて真っ赤っかに…… 私も「不安」ですし、新人の人だったら不安がいっぱいでしょうから、たくさんの小さいテストができることはあると思います。 その場合、小さい単位のテストを基盤にして、それらの学習結果やそれらの不安をもとにしたテストコードと、それらの上で実際に書かれたコードが存在することになります。 それに対して仕様変更があった場合、小さい視点のテストが全滅してしまう、もしくは真っ赤っか（テスト失敗だらけ）になってしまうということはよくあります。 そのときに、そのテストを一つ一つ直していくことに意味があるのか、割に合うのかという話が出てくると思います。実プロジェ
第9回 テスト駆動開発の「サイクル」――次にテストリストでToDoを洗い出し、レッド、グリーンでサイクルを回す | gihyo.jp
［動画で解説］和田卓人の“テスト駆動開発”講座 第9回テスト駆動開発の「サイクル」――次にテストリストでToDoを洗い出し、レッド、グリーンでサイクルを回す ニコニコ動画：https://www.nicovideo.jp/watch/sm2316617 前回は、テスト駆動開発のサイクルとしてまず最初に受け入れテストを土台として作るという話をさせていただきました。 今回は、その受け入れテストを通すために、内部の設計をどうやって行っていくかという視点の話、つまりサイクルをどうやって深堀りしていくかという話をしたいと思います。 テストリストでToDoの抽出 受け入れテストを通すために、たとえば前回紹介した『WEB+DB PRESS Vol.35』のサンプルでしたら、URLを解釈する機能が必要だなとか、XMLに変換する機能が必要だなとか、それらをつないでいくコードが必要だなとか……そういった、シス
第8回 テスト駆動開発の「サイクル」――まず受け入れテストで土台を作る | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2316518 テスト駆動開発には「リズム」と「サイクル」があります。 リズムについては前回説明しましたので、今回と次回でサイクルの話をします。 テスト駆動開発のサイクル テスト駆動開発のサイクルとは、1つの機能を実装するにあたって、どんな手順を踏んで、どういう回し方をしていくかということです。たとえば、ある1つの機能を実装したい、提供したいということになったときに、まずどういうテストを書いて、それからどういうコードを書いていくのか。 今回は、テスト駆動開発のサイクルとしてまず最初に受け入れテストを土台として作るという話をします。 そして次回、その受け入れテストを通すために、どのようにレッド、グリーン、リファクタリングというサイクルを回していくのかというお話をします。 なお、ここで説明する回し方の対象は、スタッ
第7回 「経験者」からTDDのリズムを学ぶ ――セミナー、ペアプログラミング、レビュー、動画 | gihyo.jp
［動画で解説］和田卓人の“テスト駆動開発”講座 第7回「経験者」からTDDのリズムを学ぶ ――セミナー、ペアプログラミング、レビュー、動画 ニコニコ動画：https://www.nicovideo.jp/watch/sm2316447 テスト駆動開発を学習するにあたって、前回紹介した「写経」（本を写すこと）以外にどのような方法があるかについて説明します。 経験者から学ぶ テスト駆動開発をマスターするための二つ目の道として、「テスト駆動開発の経験者から学ぶ」ということが挙げられます。具体的には、セミナーやレビュー、ペアプログラミングなどです。 セミナー テスト駆動開発のセミナーですとか、レクチャー、ハンズオンは、一定数開催されています。 テスト駆動開発はどのようなものなのか知りたい、体験してみたいと思う方は、そういうセミナーに足を運んでみるというのも一つの有効な手段ではないでしょうか。
第5回 進捗管理としてのテスト | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2196976 家永さんからの質問第3回、第4回のCustomer Testのところで「進捗管理」というキーワードが出てきましたが、ウォーターフォールの場合のバラバラで作ってあとで結合でがんばってという、そういう進捗管理とは何か違うんですか？ すみません、そこの説明は省いてしまっていました。本連載は、繰り返し型の開発をイメージして話をしています。 繰り返し型の開発とは？ 繰り返し型の開発では、たとえば1年間で何か開発するという場合に、1年間丸々使って最後にあるものができるというようなやり方ではなく、たとえば2ヵ月、3ヵ月ごとにシステムの開発する範囲を区切って、段階的に動くものをお客さまに納品していきます。もしくはお見せしていきます。 要件定義があって、外部設計があって、内部設計があってというフェーズを経る場合で
［動画で解説］和田卓人の“テスト駆動開発”講座：第4回 ナントカテスト ―― ユニットテスト，単体テスト，機能テスト，結合テスト，受け入れテスト｜gihyo.jp
［動画で解説］和田卓人の“テスト駆動開発”講座 第4回ナントカテスト ―― ユニットテスト、単体テスト、機能テスト、結合テスト、受け入れテスト ニコニコ動画：https://www.nicovideo.jp/watch/sm2195489 前回、テストをDeveloper Testing、Customer Testing、QA Testingの3つに分類しました。ここまでで何か質問はありませんか？ 担当からの質問 「受け入れテスト」というのはCustomer Testなんですか？ はい、そうです。 テストというと、よく「○○テスト」という言葉を聞くと思います。たとえば「受け入れテスト」以外にも、「ユニットテスト」「単体テスト」「機能テスト」「結合テスト」など、いろんな何々テストという言葉があります。質問にお答えする前に、まずテストの分類に対する視点を整理しましょう。 テストの分類に
第3回 「テスト」という言葉について ── Developer Testing、Customer Testing、QA Testing | gihyo.jp
［動画で解説］和田卓人の“テスト駆動開発”講座 第3回「テスト」という言葉について ── Developer Testing、Customer Testing、QA Testing ニコニコ動画：https://www.nicovideo.jp/watch/sm2195413 前回は、「テストが開発を駆動していくからテスト駆動開発」ということを説明させていただきました。しかしここで言っている「テスト」とは何でしょうか。 「テスト駆動開発」という名前を持っているからには、基盤となるのは当然「テスト」です。ですから、次に「テスト駆動開発のテストってどういうテスト？」という議論をしなければなりません。 結論を先に言いましょう。テスト駆動開発における「テスト」とは、品質のためのテストではありません。 「テスト」という言葉から連想するもの 「テスト」というと、みなさんはどのようなものを想像します
第2回 「テスト駆動開発」とは何か？ | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2195360 このWeb連載では、テスト駆動開発の啓蒙、つまりテスト駆動開発の紹介と説明を行っていきたいと考えています。そのためにはまず、「テスト駆動開発」という言葉の説明をしなければなりません。 テスト駆動開発は、よく略されて「TDD」と呼ばれます。これは「Test Driven Development」の略です。Drivenを「駆動」と訳すので、「テスト駆動開発」となるわけです。まずみなさんにテスト駆動開発とはどのようなものなのかを説明するところから、この連載を開始します。 テスト駆動開発の3ステップ テスト駆動開発は、小さなステップを繰り返してプログラムの設計と開発を行っていくソフトウェア開発手法です。テスト駆動開発は次の3ステップから構成されています。 テスト駆動開発の3ステップ ステップ1：これ
第1回 連載を始めるにあたって | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2195306 はじめまして、和田卓人（わだ たくと）といいます。 このたびgihyo.jpにて、テスト駆動開発（TDD）の連載をすることになりました。 筆者は『WEB+DB PRESS Vol.35』の特集1「実演！ テスト駆動開発」と、『WEB+DB PRESS Vol.37』の特集1「実演！ リファクタリング」を執筆させていただいた際に、同時に動画企画を行わせていただきました。おかげさまで「実演！ テスト駆動開発」と「実演！ リファクタリング」は、本誌および特設サイトの企画として、たいへん多くの方にご覧いただき、多数のご意見をいただきました。頂いたご意見の中には、以下のような意見がありました。 もう少し初心者にもわかりやすく もっと突っ込んだ内容をもう少し詳しく もう少し実践的に 特集をお読みくださった方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
