プラグマティックTDDとはなにか？ こちらの記事の翻訳になります http://adaptiveobjectmodel.com/2012/01/what-is-pragmatic-tdd/
by JOSEPH YODER on JANUARY 11, 2012
by Joseph Yoder & Rebecca Wirfs-Brock
僕らがプラグマティックTDDという言葉を使うわけ
Pragmatic Test Driven Development (TDD) is a practical approach to testing that focuses on the bigger picture of how testing best fits into and enhances your team’s software development practices. Rather than insisting that developers only write a lot of unit tests, you need to find a testing strategy that gives you higher quality software. You need to determine how testing best fits into your development context with your developers for your kind of software. プラグマティック・テスト駆動開発(TDD)は、大局的な見方を大事にしながらチームのソフトウェア開発プラクティスにテスティングをどう使えば役に立つか考えるという、テスティングのアプローチです。 開発者はユニットテストをたくさん書くべしと言ったりはしないんです。 そのかわり、より高い品質にたどりつけるよう、テスティングの戦略を見つけないといけません。 テスティングを自分の状況でどう利用するのがベストか、メンバーやソフトウェアの種類に応じて、決断する必要があるんですよ。
The typical approach to TDD usually focuses on having developers write many unit tests that may or may not add value. Instead, we recommend you adopt a testing strategy that gives you the most leverage. So, for example, rather than merely writing many unit tests, you can often get more value by defining the appropriate user-level acceptance tests. Testing should drive your development (but not at the expense of every other coding and design practice). One size or one approach for testing does not fit every organization or team. よくあるTDDは、開発者がユニットテストを多数書くことになっていますが、個々のユニットテストに価値があるかどうかはわかりません。 僕たちのオススメはこうです。 最高のレバレッジをきかせられるテスティング戦略を適用せよ。 たとえば、ユニットテストたくさんよりも、ユーザーレベルの受入テストを適切に定義するほうが価値が高いことが多いですね。 テスティングが開発を駆動するのです(ただしそれ以外のコーディングやデザインのプラクティスを捨てていいってわけでもないですよ)。 いつでもどこでも使える万能のテスティング戦略なんてのはないんです。
One thing that has discouraged people from incorporating TDD into their organization is the common misperceptions that tests should always be written first, before writing any production code, and, that tests and code should be developed in many tiny increments. We believe that TDD is more about thinking carefully about how best to validate that your software meets your requirements. Testing and validation should drive your development process (that’s why we are fans of being Test Driven), but we think there is so much more to testing than writing lots of unit tests. TDDを組織導入しない理由でよくあるのが、次のような誤解です。 いわく必ずテストを最初に書かなければいけない、プロダクションコードを1行も書く前にテストを書くのだ、テストとコードは小さなインクリメントで同時に書け、ってやつですね。 僕たちは思うんですが、TDDってむしろ自分のソフトウェアと自分の要求をどう確認(validate)するのがベストかじっくり考えようという話なんです。 テスティングと確認(validation)がセットになって、開発プロセスを駆動するべきなんですよ(なんで僕たちはテスト駆動が大好きです)。 テスティングは、ユニットテストをいっぱい書くだけの話じゃありません。
テスティングの「リズム」の違いとは何か
We believe that you should pay attention to testing and that it should be an integral part of your daily programming practice. But we don’t insist that you always evolve tests along with your code in many short cycles. Some find it more natural to outline some tests first, and use those test scenarios to guide them as they write code. Once they’ve completed a “good enough” implementation that supports the test scenarios, they then write those tests and incrementally fix any bugs as they go. As long as you don’t write hundreds of lines of code without any testing, we think this style is OK too (and we don’t insist on one style over the other). 僕たちはテスティングは大事なもので、日々のプログラミングの中の欠かせない部分だと思っています。 だけど、コードを書くときは常に小さなサイクルでテストも一緒に育てるのがいいとも限りません。 先にアウトライン的なテストのシナリオだけ書いて、そのテストシナリオをコーディングのガイドとするやり方のほうがうまくいくという人もいます。 そこそこ実装ができて想定シナリオが動かせるようになったら、そこでテストを実際に実装し、順次バグをつぶしていきます。 テスティングなしで何百行もコードを書くというのでさえなければ、こういうやりかたもアリだと僕らは思ってます(なんにせよ、どのやり方がいいという話ではありません)。
どんなテスティングプラクティスを考えるのか？
There’s a lot to becoming proficient at TDD. Developing automated test suites, refactoring and reworking tests to eliminate duplication, and testing for exceptional conditions, are just a few. Additionally, acceptance tests, smoke tests, integration, performance and load tests support incremental development as well. If all this testing sounds like too much work, well…let’s get practical. Testing shouldn’t be done just for testing’s sake. Instead, the tests you write should give you leverage to confidently change and evolve your code base and validate the requirements of the system. That’s why it is important to know what to test, what not to test, and when to stop testing. TDD上手になるのはたいへんです。 テストスイートを自動化し、リファクタリングと書き直しでテストから重複を取り除き、例外ケースをテストしと、キリがありませんね。 それに受入テスト、スモークテスト、結合、パフォーマンスや負荷テストもインクリメンタルな開発に役立つものです。 こうしたテスティングが手に負えないなあと感じましたか？ よし、それではプラクティカルになりましょう！ テスティングはテスティングのためにあらず、です。 あなたが書くテストは、あなたにレバレッジを与えるのです。 コードを変えたり育てたりするのにより自信が持てるようになり、システムが要求に合っているか確認することもできます。 だからこそ、何をテストし何をテストしないのか、どこまでテストするのか、それを知るのが大事なのです。
So, where should you start? それでどこから始めればいいのか？
It is important to establish a team testing culture. Get the team on board using similar techniques and tools. Try some different approaches and then as a group reflect on what you’ve learned (have a retrospective). If you are starting a new project you might take a quite different approach than you would with an existing code base. It’s important to not get overwhelmed. Pick an area you want to focus on. For example, it’s much easier to write unit tests for new functionality. But sometimes you want to focus on writing tests for existing code that is buggy or needs to be modified. This can be more difficult. Maybe you want to concentrate on developing integration tests and automating them first (so that you can streamline your build and deploy process). It all depends on where you want to invest first. Just start modestly, grow your testing practices, and measure the impacts of your testing effort and benefits as you go. Of course the most important thing is to start somewhere and have testing become an important part of your development process. チームにテスティングの文化を作るのが重要です。 同じ手法やツールをチームに広めましょう。 いろいろなやり方を試してみて、グループとして得たものを確認しましょう(ふりかえりをするのがいいです)。 新しいプロジェクトを始めるところなのであれば、既存コードがあるときとはアプローチががらっと変わるかもしれませんね。 圧倒されないようにしてください。 フォーカスしたいエリアを決めましょう。 たとえば、新しい機能のユニットテストを書くのは簡単です。 ですが既存コードに、バグが多いとか変更したいとかで、テストを書きたいときもあります。 こちらのほうが難しいので、先に結合テストを自動化するのにフォーカスするほうがいいかもしれません(そすればビルドとデプロイのプロセスが整理できます)。 とにかく、どこに投資したいかにかかっているわけです。 始めはほどほどに、テスティングプラクティスを育てつつ、テスティングの手間と利点を測定しましょう。 当たり前かもしれませんが、一番大切なのは実際に始めて、テスティングを開発プロセスの欠かせない一部にしていくことです。
The Refactory, Inc. principal Joseph Yoder & The Refactory, Inc. associate Rebecca Wirfs-Brock will be hosting a Pragmatic Test-driven Development course January 25-27, 2012 in the Portland Metro area. Register Now!