ソフトウェアテストの世界は広範なので、どうしても名前や定義、解釈がたくさん出てきて、認識がぶれてしまいがちです。議論をユニットテストに絞っても、ファイルに触るテストはユニットテストと呼んではならないと言う人もいれば、ファイルに触るくらいはユニットテストの範疇であると言う人もいます。ユニットテスト対象のクラス以外は全部モックでなければならないと言う人もいれば、そんなやり方では効果のあるユニットテストは書けないと言う人もいます。コンテクストを共有していない議論はどうしても炎上したり、発散したりしがちです。自分たちで定義した方が良いのではないかという話ですね。大事なのは、自分たちでテストサイズを定義して、自分たちのテストのバランスを作っていくことです。その上で、これは私の意見ですが、最終的に適切なバランスは概ねピラミッド状になると考えています。あるピラミッドですね。厚くすることによって、安定した確固たるピラミッドの土台を組み上げることができます。Test)の条件はどのようなものでしょうか。この講演では、有名な指標を2つ持ってきました。アジャイルソフトウェア達人の技』)。「F.I.R.S.T」はそれぞれ下記の性質の頭文字です。書かれるべきときに書かれている(Timely)。わかりにくいのですが、テストが自分自身で成功か失敗かを判断できる、要するにテストコードにアサーションが書かれているということです。ないテストコードは存在します。アサーションがなく、標準出力などにテスト対象の出力がそのまま出ていて、人間が目で見て期待値と一致するかどうか確かめているようなテストです。「書かれるべきとき」ですが、テスト駆動開発ではこれを実装の直前と捉えています。テスト駆動開発に拘らなければ、これは直前ではなく直後でも構いません。直前と直後にはそんなに違いはありませんが、直後と1ヶ月後には大きな違いがあります。リリース後だったり他社のエンジニアが使い始めた後だったりすると、どうしても改善に制約がかかります。書かれるべきときとは、テストコードを書くことによってプロダクトコードに設計上の良いフィードバックを返せる期間内のことです。よる「A-TRIP」です。バージョン管理/ユニットテスト/自動化』(絶版))。「A-TRIP」も、それぞれ下記の性質の頭文字です。高い水準で書かれたプロのコードである(Professional)。ここまで2つの指標を見てきましたが、これら2つの指標には重なりがありますね。2つの指標どちらにも登場する指標は何でしょうか。良いテストは互いに独立しています(Independent)。独立していないテストとは、互いに裏で関連し合って助け合ったり足を引っ張り合ったりしているテストのことです。それを読み込んで使っていることを発見してしまった。いったテストが独立していないテストです。テスト全体に対する信頼性が大きく損なわれてしまいます。良いテストはいつでもどこでも繰り返し可能/再現可能(Repeatable)です。繰り返し可能/再現可能なテストとは、例えば午前でも午後でも夜でも同じように動くし、Aさんの手元でもBさんの手元でもCIサーバ上でも同じように動くテストのことです。繰り返し可能なテストは、人間の手を介さずとも実行すれば毎回同じように動きます。2つは、他よりも少し大事な性質であると言えるでしょう。ひとつ、忘れてはならないものがあります。テストコードの話になると、なぜかコーディングレベルを下げても良いと言いだす人がいます。テストメソッド間のコードにどれだけ重複があってもいいから、単純に書かれているテストコードの方が良い。コピーアンドペーストでテストケースをどんどん増やしていった方が良い。言われていた時代もありました。その結果として、2019年の我々の目の前には、メンテナンスが必要な大量のテストコードがあります。いちど時計の針を15年前に戻して、自動テストやテスト駆動開発の啓蒙期、私たちは理想に燃えていました。「これからの時代はプログラマもテストコードを書きながら開発する時代になります。一定のスピードで開発を続けることができたりして、リファクタリングで設計もいつでも改善できる。テストを自動化しておいてよかった、という楽園が待っているんです」などと、言っていました。2019年の現在、我々の前で何が起こっているかというと......「前任者が書いたテストコードと前前任者の書いたテストコードが同時に失敗するし、内容が明らかに重複している気がする。テストコードの量が多すぎて、コードレベルだけでなく論理的も重複がありそうだけど、細部まではわからないし、2人共もういない。テストコードを消す根拠も度胸も手段もないから、歯を食いしばって全部メンテナンスしていくしかない。全体の半分くらいの時間は影響調査をしたり失敗するテストを直したりしている気がする」といった現実が待っています。こんなはずではありませんでした。そこには何が足りなかったのでしょうか。足りなかったのは、テストコードもメンテナンス対象のコードであり、つまりメンテナンスコストがかかるという認識です。ユニットテストのコードは本番コードを同じくらい専門的な標準で作成し、保守する必要があるのです。カプセル化の維持、DRY原則の遵守、結合度の軽減など、優れた設計に関する通常の規則は、本番コードと同じようにテストコードにも適用する必要があります。テストコードもプロフェッショナルの書くコードであり、つまりプロダクトコードと同じ水準、同じコーディング標準、同じ取り組み方で書いていかなければなりません。テストコードの重複には目をつぶったり、コピペもやむなしと考える人が多いのは事実です。彼らはそれではダメだと言います。code.しびれるフレーズですね。プロとしての姿勢を忘れたり、テストコードはプロダクトコードよりも質を落としてもいいという認識でいたりすると、メンテナンスコストの山がうずたかく積み上がってしまう。いうことを再び考え続けなければならない曲がり角に立っている2019年なのです。講演はそろそろ終わりになりますが、本日の講演では、まず動作するきれいなコードに至るための道の話をしました。動作するきれいなコードに至ったら終わりではなく、動くコードに触り続け、動作するきれいなコードであり続けさせる必要があります。そのためにはフィードバックサイクルの回転が重要であり、その回転を続ける手段のひとつとしてテスト駆動開発があり、そのテスト駆動開発が大事にしているものが、細かいステップのサイクルであり、それによって打たれ弱いリファクタリングを保護し、リファクタリングを必要十分に行うこともできました。テスト駆動開発の回転の外にも自己相似形の様々な半径のフィードバックサイクルを回すことが重要です。テストだけでなくユニットテストも非常に重要なのか、良いユニットテストはどのようなものなのか、という話をしました。講演の最後に、私が書籍『テスト駆動開発』を訳している過程で最も印象に残っているフレーズを引用して講演を終わりにしたいと思います。テスト駆動開発は、設計のひらめきが正しい瞬間に訪れることを保証するものではない。自信を与えてくれるテストときちんと手入れされたコードは、ひらめきへの備えであり、いざひらめいたときに、それを具現化するための備えでもある『テスト駆動開発』翻訳者としての私は、このフレーズが一番好きです。テスト駆動開発の大事なところが詰まっているフレーズであるとも思います。私の講演はこれで終わりにしたいと思います。当日は日英の同時通訳が付きました。国際カンファレンスの基調講演は初めての経験だったのですが、資料作成から当日まで、国際カンファレンスならではの違いがいくつかありました。資料作成の締め切りが早い資料をすべて英語で作成する必要がある講演前に同時通訳者さんと綿密な打ち合わせを行うこのため、普段の講演とは異なる作戦で臨みました。講演者用ノートを全く使いませんが、このときばかりはかなりの分量の原稿を書きました。準備したおかげで当日の講演は成功し、ありがたい評価をいただいたのですが、後日困ったのが資料公開です。文字が少なく図や写真が多い講演資料は、それだけを公開してもなかなか内容が伝わらないのです。この点を悩んだまま時間だけが過ぎていきました。登壇しました」を思い出しました。このエントリはとても印象に残っていて、私も今回かなりの分量のスピーチ原稿を書いたのだから、スライド公開だけでなく、スピーチ原稿を合わせて公開するスタイルを一度やってみようと思い立ったのでした。私は壇上で結構アドリブを入れたり、聴衆の反応を見て説明を変えたりします。スピーチ原稿とは違う表現で話したり、原稿に無いことを壇上で喋ったりもしています。このため今回は文字起こしも行うことにしました。残っており、この動画を文字に起こし、スピーチ原稿と文字起こしをマージしながら加筆修正すれば良い結果になるだろうと考えました。参加を締め切りとして、作業を進めていこうと考えました。実際に作業を始めてみると、文字起こしに非常に時間がかかりました。私の話は長いですね......。作業が終わった頃には、クリスマスもまた終わっていたのでした......(すみません、本当にすみません)。登壇を支えてくださった全ての方に感謝します。誠にありがとうございました。このエントリが読者の皆様の参考になれば幸いです。この文章はテスト容易性設計をテーマに...2019-01-032018年のアウトプットまとめ2018年は公私ともに忙しい年でした。まさーるさん(石井勝さん)を偲ぶ。現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ2018年のアウトプットまとめ新訳版『テスト駆動開発』が出ますOSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか?月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。