TDDは死んだ。テスティングよ栄えよ。 by DHH

DHHの"TDD is dead. Long live testing."を、訳してみました。

翻訳 やっとむ

By David Heinemeier Hansson on April 23, 2014

David Heinemeier Hansson 2014年4月23日

Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming.

テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。

It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happened before. It opened my eyes to the tranquility of a well-tested code base, and the bliss of confidence it grants those making changes to software.

最初からこうだったわけではない。私が初めてTDDに出会ったときには、よりよいソフトウェア開発の世界へ丁重に招待されたように感じた。テスティングが存在しない世界からテスティングのプラクティスへのマインドハックだ。十分にテストされているコードベースに感じる落ち着き、ソフトウェアを変更するときの安心感を教えてくれた。

The test-first part was a wonderful set of training wheels that taught me how to think about testing at a deeper level, but also some I quickly left behind.

テストファースト」は自転車の補助輪のようなもので、テスティングをより深いレベルで考えるやりかたを教わる役に立ったが、私はすぐに外してしまった。

Over the years, the test-first rhetoric got louder and angrier, though. More mean-spirited. And at times I got sucked into that fundamentalist vortex, feeling bad about not following the true gospel. Then I'd try test-first for a few weeks, only to drop it again when it started hurting my designs.

月日が過ぎたが、しかしテストファーストのレトリックはより騒々しく、怒りっぽいものとなってきた。より狭量になってきた。ときどき私も原理主義の渦に巻き込まれて、真の教義に従っていないのが悪いことだと感じることもあった。それでテストファーストを何週間かやってみるのだが、そのせいで設計が悪化するため、辞めるのだ。

It was yoyo cycle of pride, when I was able to adhere to the literal letter of the teachings, and a crash of despair, when I wasn't. It felt like falling off the wagon. Something to keep quiet about. Certainly not something to admit in public. In public, I at best just alluded to not doing test-first all the time, and at worst continued to support the practice as "the right way". I regret that now.

教義の一言一句通りにできるとプライドが高まり、その通りにできないと絶望にうちひしがれるという、プライドのヨーヨーのようだった。バスから下ろされたような気分だった。内緒にしておくべき話だ。公に認められるような話では絶対にない。公には、良いときで、私はテストファーストを常にやっているわけではないとほのめかし、悪いときにはテストファーストを「正しいやり方だ」と支持してきた。今では後悔している。

Maybe it was necessary to use test-first as the counterintuitive ram for breaking down the industry's sorry lack of automated, regression testing. Maybe it was a parable that just wasn't intended to be a literal description of the day-to-day workings of software writing. But whatever it started out as, it was soon since corrupted. Used as a hammer to beat down the nonbelievers, declare them unprofessional and unfit for writing software. A litmus test.

当初は、テストファーストを「直感に反する破壊槌」として、自動化したリグレッションテスティングが存在しないという残念な業界の現状を打破する必要があったかもしれない。当初は、文字通りに受け止めるべきではないたとえ話として、日々のソフトウェア開発でそのまま使うつもりではなかったのかもしれない。しかしそうして始まったとしても、いまでは堕落してしまったのだ。不信心者を打ち据えるハンマーとなり、プロフェッショナルにもとるソフトウェア開発に向かない人だと決めつける。リトマス試験紙だ。

Enough. No more. My name is David, and I do not write software test-first. I refuse to apologize for that any more, much less hide it. I'm grateful for what TDD did to open my eyes to automated regression testing, but I've long since moved on from the design dogma.

十分だ。もうやめよう。私の名前はDavid、ソフトウェアをテストファーストでは書かない。そのことについてもう謝らないし、ましてや隠したりしない。自動化したリグレッションテスティングに私の目を開かせてくれたことについて、TDDには感謝しているが、設計の教義としてはとっくに使わなくなっている。

I suggest you take a hard look at what that approach is doing to the integrity of your system design as well. If you're willing to honestly consider the possibility that it's not an unqualified good, it'll be like taking the red pill. You may not like what you see after that.

私はあなたに提案したい。テストファーストのアプローチが、あなたのシステムの設計の完全性や一貫性にどう影響しているか、厳しく見直してほしい。もしも「文句なしによい」とは限らないという可能性について、誠実に考えてみるならば、あなたはレッドピルを飲むことになるかもしれない。発見するものが気には入らないかもしれない。

それではどこに向かえばいいのだろうか? So where do we go from here?

Step one is admitting there's a problem. I think we've taken that now. Step two is to rebalance the testing spectrum from unit to system. The current fanatical TDD experience leads to a primary focus on the unit tests, because those are the tests capable of driving the code design (the original justification for test-first).

最初のステップとして、問題の存在を認めよう。ここまではもう来ていると思う。次のステップとして、ユニットからシステムへ広がるテスティングのスペクトラムのバランスを取ろう。現在の狂信的なTDD運動では、ユニットテストを一番にフォーカスしがちだ。コードの設計を駆動するのがユニットテストだからだ(そもそものテストファーストの理由だ)。

I don't think that's healthy. Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.

私には不健康なやり方に思える。テストファーストユニットテストは、中間的オブジェクトや間接的で過剰に複雑な構造を生みがちだ。「遅い」ものをすべて避けようとするのがその理由で、データベースやファイルIOなどを避ける。ブラウザを使ってシステム全体をテストするのも避けようとする。結果として、本当に恐ろしく巨大なアーキテクチャが生まれてしまう。サービスオブジェクトやコマンドパターン、さらにひどいものたちが絡み合ったジャングルだ。

I rarely unit test in the traditional sense of the word, where all dependencies are mocked out, and thousands of tests can close in seconds. It just hasn't been a useful way of dealing with the testing of Rails applications. I test active record models directly, letting them hit the database, and through the use of fixtures. Then layered on top is currently a set of controller tests, but I'd much rather replace those with even higher level system tests through Capybara or similar.

私は伝統的な意味でのユニットテストはほとんどしない。すべての依存関係をモックにし、何千というテストが数秒で終わるようなユニットテストのことだが。Railsアプリケーションのテスティングにおいてはいいやり方ではないという、ただそれだけだ。私はアクティブレコードを直接、データベースをアクセスし、フィクスチャを使ってテストする。上のレイヤにはコントローラのテストがあるが、私はどちらかというとさらに上位のシステムテストを、Capybaraや類似のものを使ってテストする。

I think that's the direction we're heading. Less emphasis on unit tests, because we're no longer doing test-first as a design practice, and more emphasis on, yes, slow, system tests. (Which btw do not need to be so slow any more, thanks to advances in parallelization and cloud runner infrastructure).

これが我々の向かう方向だと思う。ユニットテストの重要度を下げる。設計のプラクティスとしてはテストファーストを使わないからだ。そしてより遅いシステムテストの重要度を上げる。(ところで、並列でクラウドで実行するインフラのおかげで、以前のように遅いわけではない。)

Rails can help with this transition. Today we do nothing to encourage full system tests. There's no default answer in the stack. That's a mistake we're going to fix. But you don't have to wait until that's happening. Give Capybara a spin today, and you'll have a good idea of where we're heading tomorrow.

Railsはこうした移行の手助けになりうる。今日、我々は完全なシステムテストを推進するためになにもしていない。スタックにデフォルトの正解を準備していない。我々はこうした間違いを直していくつもりだ。だが直るのを待っている必要はない。Capybaraを試してみれば、我々が明日向かっていく方向がわかるはずだ。

But first of all take a deep breath. We're herding some sacred cows to the slaughter right now. That's painful and bloody. TDD has been so successful that it's interwoven in a lot of programmer identities. TDD is not just what they do, it's who they are. We have some serious deprogramming ahead of us as a community to get out from under that, and it's going to take some time.

だがまずは深呼吸しよう。我々が今やろうとしているのは、聖なる牛の屠殺である。痛々しいし、血がたくさん出る。TDDはあまりに成功してきたため、多くのプログラマアイデンティティに埋め込まれてしまっている。TDDは単なる手法ではなく、彼ら自身がTDDになっているのだ。そうした人を元に戻すためコミュニティとして真剣に取り組まなければならないし、そのためには時間が必要だ。

The worst thing we can do is just rush into another testing religion. I can just imagine the golden calf of "system tests only!" right now. Please don't go there.

最悪のやり方は、また別のテスト宗教に駆け込むことだ。「システムテストがすべてだ!」という黄金の牛の偶像がありありと目に浮かぶ。どうかそうはしないでほしい。

Yes, test-first is dead to me. But rather than dance on its grave, I'd rather honor its contributions than linger on the travesties. It marked an important phase in our history, yet it's time to move on.

そう、私にとってテストファーストは死んだ。だがその死を利用したり、悪い点を述べるのではなく、貢献を称えたい。我々の歴史上に、重要なフェーズを刻んだ。次へ進むべき時だ。

Long live testing.

テスティングよ栄えよ。

Continue down the rabbit hole with Why Most Unit Testing is Waste by James Coplien and my RailsConf keynote on Writing Software: Part 1 (starts at 11:00), Part 2.

ウサギの穴をより深く進むにはWhy Most Unit Testing is Waste by James Coplien、私のRailsConfのWriting SoftwareキーノートのPart1(11:00から)、Part2

付記

翻訳の間違いなどの責任はやっとむ(tsutomu.yasui at gmail.com)にあります。コメントなどで指摘していただけると嬉しいです。

4月24日(木)お昼ごろのものをベースに訳しました。