JUnit A Cook's Tour 4. Conclusion翻訳メモ

JUnit A Cook's Tour の「4. Conclusion」を雰囲気でほにゃくしてみる。
☆はよくわかんないところ。
ほんやくこんにゃくホシイ。

----

4. Conclusion
4.結論

To conclude, let’s make some general observations:
結論として、全体を見てみましょう

Patterns
パターン

We found discussing the design in terms of patterns to be invaluable, both as we were developing the framework and as we try to explain it to others.
設計をパターンの単位で議論することは、フレームワークの開発とフレームワークを他者に説明する上で有益であることが分かりました。

You are now in a perfect position to judge whether describing a framework with patterns is effective.
あなたは、現在、あるフレームワークが効果的なパターンで記述されているか判断できる最適な立場にあります。

If you liked the discussion above, try the same style of presentation for your own system.
もし上記のような議論が好きなら、自分のシステムのために同じスタイルのプレゼンテーションを試してみてください。

Pattern density
パターンの密度

There is a high pattern "density" around TestCase, which is the key abstraction of JUnit.
TestCaseのまわりには高いパターンの「密度」があります。そして、それはJUnitの鍵となる抽象概念です。

Designs with high pattern density are easier to use but harder to change.
高密度なパターンによる設計は、使いやすいのですが、変更が困難です。

☆We have found that such a high pattern density around key abstractions is common for mature frameworks.
成熟したフレームワークではそういった鍵となる抽象概念による高密度なパターンは一般的であることがわかりました。

☆The opposite should be true of immature frameworks - they should have low pattern density.
反対に、未熟なフレームワークではパターンの密度が低いはずです。

☆Once you discover what problem you are really solving, then you can begin to "compress" the solution, leading to a denser and denser field of patterns where they provide leverage.
いったんあなたが本当に解決したい問題を発見したら、あなたは解決策を圧縮して、パターンが提供する、より高密度な領域に導いてくれます。


Eat your own dog food
あなた自身のドッグフードを食べてください(他人に提供するものはまず自分で試してみましょう)

As soon as we had the base unit testing functionality implemented, we applied it ourselves.
我々は基本単位のテストが機能するところまで実装したらすぐに、我々自身でそれを適用しました。

☆ A TestTest verifies that the framework reports the correct results for errors, successes, and failures.
TestTest(Testインターフェースのためのテスト？)は、フレームワークがエラーや成功、失敗などの適切な結果をレポートすること検証しています。

We found this invaluable as we continued to evolve the design of the framework.
我々がフレームワークのデザインを発展させ続けたので、こういった内容は非常に貴重であるとわかりました。

We found that the most challenging application of JUnit was testing its own behavior.
JUnitで最も挑戦的なアプリケーションは、JUnitがJUnit自体のふるまいをテストしていることであることを見いだしました。



Intersection, not union
交差、結合ではなくて。

There is a temptation in framework development to include every feature you can.
フレームワーク開発では、できるだけいろんな機能を取り込みたいという誘惑があります。

After all, you want to make the framework as valuable as possible.
結局、あなたはフレームワークをできるだけ価値のあるものにしたいのです。

However, there is a counteracting force- developers have to decide to use your framework.
しかし、開発者があなたのフレームワークを使うことを決心させなければならない反作用（ジレンマ？）があります。

The fewer features the framework has, the easier it is to learn, the more likely a developer will use it.
機能が少ないフレームワークは、学習が容易で、開発者に使われやすいでしょう。

JUnit is written in this style.
JUnitは、このスタイルで書かれています。

It implements only those features absolutely essential to running tests- running suites of tests, isolating the execution of tests from each other, and running tests automatically.
JUnitはテストを走らせるために厳選された機能だけを実装しています。それは、テスト１式を走らせること、お互いに独立したテストの実行、自動的にテストを走らせることなどです。

Sure, we couldn’t resist adding some features but we were careful to put them into their own extensions package (test.extensions).
もちろん、私たちは若干の特徴を加えることを抑えることができませんでした。しかし、それは拡張パッケージ(test.extensions)の中に、注意深く取り込みました。

A notable member of this package is a TestDecorator allowing execution of additional code before and after a test.
この拡張パッケージで特筆すべきクラスはTestDecoratorで、TestDecoratorはテストの前後に追加コードを実行できるようにしています。


Framework writers read their code
フレームワークの記述者は、自分のコードを読みます

We spent far more time reading the JUnit code than we spent writing it, and nearly as much time removing duplicate functionality as we spent adding new functionality.
我々がJUnitのコードを読んでいる時間は、JUnitのコードを書いた時間よりも遥かに多くの時間を費やしています。
そして、新しい機能を追加している時間とほとんど同じくらいの時間を重複機能の除去に費やしています。

We experimented aggressively with the design, adding new classes and moving responsibility around in as many different ways as we could imagine.
我々は新しいクラスを加えたり、想像できるあらゆる方法で責務を移動したりして、積極的に設計を試しました。

☆We were rewarded (and are still being rewarded) for our monomania by a continuous flow of insights into JUnit, testing, object design, framework development, and opportunities for further articles.
JUnitへの洞察、テスト、オブジェクトデザイン、フレームワーク開発、そしてさらなるものへのチャンスといった、我々の執拗で継続的継続的なフローによって、我々は恩恵を受けています。（そしてこれからも）



The latest version of JUnit can be downloaded from http://www.junit.org.
JUnitの最新版は、http://www.junit.org.からダウンロードできます。