「自動テストとテスト駆動開発、その全体像」を執筆しました（Software Design 2022年3月号）

tdd programming

【更新】寄稿した記事が Web に公開されました

技術評論社様のご厚意により、 Software Design 2022年3月号に寄稿した「自動テストとテスト駆動開発、その全体像」が gihyo.jp にて公開されました。誠にありがとうございます！

gihyo.jp

はじめに

2022年2月18日発売の Software Design 2022年3月号 にて、第2特集「そろそろはじめるテスト駆動開発」の第1章「自動テストとテスト駆動開発、その全体像」を執筆いたしました。第1章では、混同されることの多い自動テスト関係の概念を自動テスト、テストファースト、テスト駆動開発（TDD: Test-Driven Development）の3つの段階に分け、それぞれの効果や注意点を包括的に整理整頓しています。

ソフトウェアデザイン 2022年3月号

ソフトウェアデザイン 2022年3月号

Amazon

gihyo.jp

gihyo.jp

第2特集
そろそろはじめるテスト駆動開発
JavaScriptでテストファーストに挑戦
…… 和田 卓人（監修）

第1章：保守しやすく変化に強いソフトウェアを支える柱
自動テストとテスト駆動開発，その全体像
…… 和田 卓人

第2章：TDDのその前に
自動テストの環境を構築しよう
…… 櫛引 実秀

第3章：レッド・グリーン・リファクタリングのリズムを体験
実践！ テストファースト
…… 櫛引 実秀

私が書いた第1章のポイントは下記のものです。

  • 自動テスト関係のプラクティスを 1.自動テスト 2.テストファースト 3.テスト駆動開発 の3段階に分ける
  • 3つそれぞれの効果や注意点を包括的にまとめる
  • テスト駆動開発まで行かずとも、自動テストを行えば十分価値があると伝える

このエントリでは執筆の背景や動機、執筆のプロセスなどを説明します。

目次

執筆の背景

昨年末にオファーをいただいたときは執筆を引き受けようか迷いましたが、書籍『テスト駆動開発』を翻訳した際に執筆した「付録C」と対になるような文章を書こうと思いました。

テスト駆動開発（Test-Driven Development）という言葉が生まれたのは2002年。もう20年前です。その間にどのような歴史があったかは、書籍『テスト駆動開発』の「付録C」やXP祭り2018の基調講演「テスト駆動開発の過去・現在・未来」にまとめました。

テスト駆動開発

テスト駆動開発

Amazon

その付録Cのなかに、今回の執筆の動機となる「意味の希薄化」が出てきます。

動機は「意味の希薄化」

対象のコードに対してテストコードを書きテスト実行の自動化を行う自動テスト（Automated Test）は20年の間に多くの組織に広まりました。一方テストファーストやテスト駆動開発はというと、自動テストほどは行き渡らず、一部の個人が選択する開発スタイルのひとつに落ち着きました（これは妥当なところでしょう）。

そこまでは良かったのですが、20年のうちに「意味の希薄化」が発生しました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象で、名付け親は Martin Fowler です。

Software Design 2022年3月号第2特集第1章冒頭には、次のように書きました。

テスト駆動開発（TDD:Test-Driven Development）という名前は、現在では多くのエンジニアに広まっていますが、そこにはやや混乱も見られます。「TDD」という言葉が指しているものが人によって異なるのです。自動テストを書くことを TDD と呼ぶ人もいれば、テストを先に書くこと(テストファースト)を TDD と呼ぶ人もいます。TDD の利点を説く人の説明をよく読んでみると、自動テストの利点や、テストファーストの利点のことを述べているような場面に出会うことも多々あります。

意味の希薄化の例として印象に残っているのは応用情報技術者試験です。正解は「エ」とありますが、「イ」も正解と言えます。ここからはテスト駆動開発がテストファーストと混同されていることが読み取れます。

語彙の混乱は会話のコストを上げてしまう頭の痛い問題です。「テスト駆動開発」という言葉が出るたびに、それが何を指しているかを状況毎に翻訳し続けなければならないからです。

執筆依頼をいただいたことを契機として、語彙の再整理を行いたいと考えました。自動テスト、テストファースト、テスト駆動開発を分けて、それぞれの利点や注意点を包括的に整理整頓できれば、「テスト駆動開発というものをちょっとやってみよう」や「私たちは自動テストで十分だ」という判断を支援できないかと考えた次第です。

Software Design 誌は久しぶり

同じ技術評論社の WEB+DB PRESS には何度か書かせていただいていますが、雑誌記事を初めて書いたのは実は Software Design 誌で、同誌への執筆はそれ以来となる17年1ヶ月ぶりです。17年前に書いたのは特集「今すぐできるCVS環境」の「1章：なぜなにCVS」でした。 CSV ではなく CVS です。いま我々が主に使っているバージョン管理システムは Git ですが、その前は Subversion、さらにその前が CVS ということで、時代を感じます……。

第2特集 今すぐできるCVS環境

1章：なぜなにCVS……和田卓人

Software Design 2005年2月号｜技術評論社

共著は @Panda_Program さん

今回の特集は共著です。3章構成の第1章と全体の監修が私で、第2章と第3章を書いてくださったのがパンダさん（@Panda_Program さん）です。 パンダさんはテスト駆動開発のハンズオンイベント TDD Boot Camp （#tddbc） で知り合った、情報発信も積極的に行っているソフトウェアエンジニアです。今回の企画を行った技術評論社の中田さんからパンダさんに執筆依頼があり、私には第1章の著者として後から白羽の矢が立ったのだろうと考えています。

パンダさんが今回の記事を書いた背景や動機は、TDDの勉強会に参加したらSoftware Designに寄稿することになった話 - パンダのプログラミングブログ をご覧ください。胸の熱くなるエントリです。

企画は中田さん、編集は山本さん

特集の企画は技術評論社の 中田 (@akito912912) さん、第1章の編集制作作業をしてくださったのは技術評論社の 山本 (@hyamamoto144) さんです。 私の遅筆により、お二人には本当にご迷惑をおかけしました……構成から執筆まで信頼して任せてくださったことを感謝しております。

執筆後に山本さんにこう言っていただけて救われました。誠にありがとうございます。

執筆の進め方

執筆を引き受けたはいいものの、包括的にまとめるというゴールを自分で設定してしまった結果、プレッシャーに悩むことになりました。私はプレッシャーにはインプットの量で立ち向かいます。とにかくインプットの量を増やしてまとめることをベースにして、下記の作戦を立てました。

  • 自動テストやテスト駆動開発について言及している書籍や記事を集め、言及している部分を全て書き出す
  • その記述を「自動テスト、テストファースト、テスト駆動開発」x「利点（pros）、注意点（cons）」の6つの区画のどれに該当するかマッピングする
  • 6区画の中身をそれぞれ整理整頓し、雑誌記事として執筆する

参考文献からひたすらインプット

インプットとしては、具体的には下記の書籍の言及箇所をテキストに書き出しました。これら書籍においてもテスト駆動開発の説明はやや混乱しており、それらの記述を再整理してみたい、再整理したらどうなるか見てみたいという思いも今回の執筆の隠れた動機としてはありました。

特に最後の2冊『A Philosophy of Software Design』と『アジャイルイントロダクション』は自動テストの価値を高く認めるもののテスト駆動開発には懐疑的な立場をとっており、これら書籍からの意見も取り入れたいと考えました。また、『xUnit Test Patterns: Refactoring Test Code』は知見が整然と包括的にまとまっており、さすがだなという印象でした。

マッピングと整理整頓

次に、そのテキストを文やある程度のまとまりの単位で分解し、マインドマップ形式でツリー構造にしていきます。

今回はマークダウンでツリーを書ける markmap の VSCode 拡張である Markmap - Visual Studio Marketplace を使いました。この Markmap 拡張は非常に良く出来ていて、講演や執筆の構成を練るためによく使っています。

ツリーがある程度まとまったら紙に印刷し、それぞれの文章が何に言及しているのかを3色ペンで自動テスト（赤）、テストファースト（青）、テスト駆動開発（緑）の印をつけていきます。印刷して手を動かす工程は非効率に思えますが、私の場合は一度紙に出してペンで書き込む方が考えがまとまる側面があり、ときどき紙を経由しています。

この工程を終えるとツリーの枝が3色どれかになっているので、今度は同じ色の枝を集めていけば、まずはインプットを3つに分類できます。あとは1つの色の中で、それぞれの文章が利点について述べているのか注意点について述べているのかを分ければ6区画ができあがります。

6区画ができあがったら、区画の中を整理していきます。同じ区画には異なる書籍から似たような記述が集まっていますので、それを KJ 法などを使っていくつかの項目にまとめます。これがツリーの最下位レベルの枝になります（各文章が葉です）。

アウトライン作成から執筆へ

ここまでの工程で全体の枝構造が得られたので、次にこれを記事のアウトラインに移植していきます。インプットをまとめたツリーのレベルを1段階シフトして葉を落とし、最下位レベルの枝を葉にしたものがアウトラインの原型になります。

記事アウトラインのツリー構造もマークダウンで書き、Markmap - Visual Studio Marketplace で可視化します。執筆自体は慣れた Emacs で行うので、デスクトップ左半分に VSCode の Markmap を表示し、右半分では Emacs で執筆するという奇妙な構成になりました。Emacs でアウトライン原稿のマークダウンファイルを編集すると VSCode が Markmap を再描画して即時フィードバックが働きます。

ここで、テストファーストとテスト駆動開発の記述に比べて自動テストの記述の分量が非常に多いことに気づきます。これはある意味当たり前で、3つの中では自動テストが最も価値がある基盤技術であり、テストファーストやテスト駆動開発は自動テストの問題点を補い、効果をさらに高めていく手法だからです。ということで分量の比率はそのままに、自動テストの部分だけさらに細分化してアウトライン化していきます。

アウトラインが完成したら全体の構成はできあがっているので、あとはひたすら中身を埋めていきます。葉レベルの箇条書きを文章に書き直していくイメージです。

章タイトルも企画段階では「テスト駆動開発超入門」という仮タイトルでしたが、この段階で内容を反映した「自動テストとテスト駆動開発、その全体像」に変更しました。

初稿提出、校正

マークダウン形式のファイルの形で初稿を提出し、台割や組版を編集の皆さんに委ねます。初稿のゲラが pdf として返ってきたら、著者校正のプロセスに入ります。

今回は細かい修正が非常に多かったので、pdf を印刷して校正記号を入れ、スキャンして返すという手法を選択しました。テキストや diff にするとかなり量が増えてしまうのと、既に組版と校正のプロセスに入っているので、記事に校正記号を入れていく方が正確に伝わると判断したためです。

このような校正を数回やりとりして脱稿し、印刷所に入ります。編集制作作業をしてくださった技術評論社の山本さんには本当にお世話になりました……。

おわりに

最後にもう一度繰り返しますと、2022年2月18日発売の Software Design 2022年3月号 にて、第2特集「そろそろはじめるテスト駆動開発」の第1章「自動テストとテスト駆動開発、その全体像」を執筆いたしました。私が書いた第1章のポイントは下記のものです。

  • 自動テスト関係のプラクティスを 1.自動テスト 2.テストファースト 3.テスト駆動開発 の3段階に分ける
  • 3つそれぞれの効果や注意点を包括的にまとめる
  • テスト駆動開発まで行かずとも、自動テストを行えば十分価値があると伝える

ここまで書いてきたとおり、結構力を入れています。自動テスト、テストファースト、テスト駆動開発それぞれの説明、効果、注意点を包括的にまとめていますので、自分の理解を確認するだけでなく、他の人に説明するためにも使える記事になっていると考えています。

gihyo.jp

gihyo.jp

このエントリでご興味をお持ちくださいましたら、ぜひお手にとっていただけますと幸いです。 また、雑誌記事をお読みくださった方は、ブログや Twitter など何らかの形で感想を書いていただけますと非常に嬉しく、とても励みになります。 何卒よろしくお願いします。