CodeZine(コードジン)

特集ページ一覧

達人の手ほどきで、正しい方向に一歩踏み出そう
~アジャイルアカデミー「TDD実践講座」体験レポート

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2015/06/12 14:00

 今月の開催で2周年を迎える「アジャイルアカデミー」。会社研修の一環などを想定し、業界の第一人者による少人数のワークショップ形式で構成された本講座は、2013年6月の開講以来、リピーターや受講者の推薦による参加が多く、大変好評いただいています。今回、ドッグフーディングということでCodeZine編集部でも、講座の一つ「TDD実践講座」を体験してみました。その模様をお伝えします。

目次

アジャイルアカデミー「TDD実践講座」とは

 「TDD実践講座」は、ソフトウェア開発手法の一つ「テスト駆動開発(TDD)」の実践手法を手引きする講座です。

 TDDは、CodeZineの連載『C#で始めるテスト駆動開発入門』をはじめとする多くの日本語のドキュメントや、「TDD Boot Camp」といったコミュニティ活動によって普及しており、既にご存じの方、実践されている方も多いでしょう。

 一方で、知名度が高い分、「大枠は理解しているけれども実践となると自信がない」「気になってはいるが、独学で調べてたり、コミュニティ活動に参加したりする時間が取れない」といったこともあるかもしれません。

 本講座は、そのような悩みを抱える方に向けて、国内におけるTDDの伝道師 和田卓人氏、TDDのエキスパート 太田健一郎氏、安井力(やっとむ)氏といった布陣で、開発の現場で役立つ、最も効率的なTDD導入の勘所をレクチャーする内容となっています。

 講座のコンセプトについては、以前CodeZineに掲載した『「書くコードに自信と責任を持ったプロフェッショナルになるために」 ~アジャイルアカデミー開講記念インタビュー』も併せて参照してください。

講座受講に必要なスキル

 アジャイルアカデミーは、実際に手を動かすワークショップ形式で、受講者の積極的な参加を重視した構成となっていますが、冒頭に簡単な座学とデモンストレーションがあるため、TDDの基礎知識がない方でも安心して受講いただけます。

 また、技術的にも、何かしらの開発言語を習得しているレベルであれば十分です。単体テストツールの使い方も、スニペットなどが用意されており、職業プログラマーではない編集者でも十分ついていくことができました。

 例えば、JavaScript(単体テストフレームワークとしてQUnit)であれば、次のようなサンプルが用意されています。

module("QUnit の使い方");

test( "assert.ok の使い方", function(assert) {
  var truth = true;
  assert.ok(truth, "assert.ok は引数が truthy であるかどうかを検証します");

  var falsy = null;
  assert.ok(!falsy);
});

// QUnit の assert.equal 系は引数の順番が actual, expected の順(JUnit の逆)なので注意してください

test( "equal, notEqual の使い方", function(assert) {
  assert.equal('hoge', 'hoge');
  assert.equal(1, '1', 'equal は == を使います');
  assert.notEqual('foo', 'bar');
});

……

 なお、当日はいくつかのチームに分かれて共同作業を行うため、事前にアンケートを行い、開発言語ごとの振り分けが行われます。

TDDを行うべき理由

 講座が始まると、まず受講者各位がポジションペーパーを書き、自己紹介と参加理由を発表します。参加した回では、社内システムやネットワークインフラ回りを担当されている方が多く、上長からの推薦や部署の意向で受講されたようでした。

 具体的な参加目的としては、次のようなものを挙げていました。

  • スクラムでTDDをやっているが、一から学び直したい
  • 引き継いだコードをきれいにしたい
  • 自動化まで踏み込みたい
  • そもそもTDDとは何かを知りたい

 続いて、TDDというのは、複雑さに立ち向かい、不安を克服し、状況をコントロールする手法であり、目標は、「動作するきれいなコード(バグ対応も追加変更も容易で、作業が予測可能なコード)」を書くことであることを、当日講師を務めたやっとむ氏が説明(注:講師・チューターは開催回ごとにローテーションします)。予測可能であることが、ビジネス・企画側も含めたチームに信頼性を生むと、TDDのメリットを再確認しました。

 その後、TDDの具体的な方法論の解説が続きますが、この辺りはCodeZineでも何回か取り上げていますので割愛します。詳しくは次の記事などを参照ください。

座学の様子。2~4名単位のチームで、テーブルが分けられている
座学の様子。2~4名単位のチームで、テーブルが分けられている

TDDで扱うテストの性質

 具体的な演習に進む前に、強調しておくべき点として、TDDのテストの性質について注意がありました。

  • TDDのテストは、プログラマーの、プログラマーによる、プログラマーのためのテストである
  • テストにはさまざまな種類があるが、TDDがカバーしているのは、その一部であり、品質のためのテストの代わりになるものではない
  • TDDのテストは、「高速」「独立」「再現性」「自己検証可能」「適時性」(頭文字をとってFIRST)の5つの要件を満たす必要がある(『Clean Code』より)

 このようなTDDを体験するための前提知識の解説と、FizzBuzz問題を題材にしたデモンストレーションに続いて、受講者は早速、実際にコーディングを行うハンズオンに取り掛かります。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 斉木 崇(編集部)(サイキ タカシ)

    メディア編集部 メディア1(CodeZine/EdTechZine/ProductZine)編集統括 兼 EdTechZine/ProductZine編集長。1978年生まれ。早稲田大学大学院理工学研究科(建築学専門分野)を卒業後、IT入門書系の出版社を経て、2005年に翔泳社へ入社。ソフトウェア開...

All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5