
Guice(ジュース)を早飲みしすぎていませんか?
あなたのチームが、既存アプリケーションを「シングルトンの入れ子」設計から依存性注入(DI)へ移行しようとしているなら、この論文に心引かれるでしょうが、DIへの移行は難しいことが分かっています。論文にはGoogleのJava DIコンテナ(Guice)の名を入れていますが、Javaや.NET、Python、Rubyなどにも当てはまります。

あなたのチームが、既存アプリケーションを「シングルトンの入れ子」設計から依存性注入(DI)へ移行しようとしているなら、この論文に心引かれるでしょうが、DIへの移行は難しいことが分かっています。論文にはGoogleのJava DIコンテナ(Guice)の名を入れていますが、Javaや.NET、Python、Rubyなどにも当てはまります。

アプリケーションのパフォーマンスを考えたとき、我々はアプリケーションが完成に近づくまでは、パフォーマンスのテストを滅多に行いません。我々が機能テストで行ってきた、反復、自動化、継続という教えをパフォーマンスについても同様に適用できるでしょうか?
単体テストで日付と時間をでテストする方法はよく話題にあがるが、比較的簡単な解決策がある。もっと難しいのは、時間を受け入れ/システムテストでテストすることだ。どんな方法があるだろうか。
著名なアジャイリストでテスト駆動開発のエキスパートでもあるJ.B.Rainsberger氏(J.B. Rainsberger)が始めたブログでの連載では、「結合テストはでたらめだ」という考えさせられる見解になぜ氏が行き着いたかの説明がなされている。
先日のTest-Driven Development(テスト駆動開発)Yahoo groupsでの議論で関心を集めたのは、TDDに対するいわゆる「古典派」のアプローチと「モック派」のアプローチとのつながりについてだ。
数カ月前にC++テストフレームワークをオープンソースにした後、GoogleはBSDライセンスのもと、Google C++モッキングフレームワーク(Google Mock)をオープンソースにした。
有名なRhino Mocks.NETモックフレームワークのバージョン3.5がリリースされている。このバージョンは、APIにおいて大きな変化と言える。
Mockito mockフレームワークの最近のリリースは、非mockオブジェクトの偵察を可能にし、またより明確なスタブ構文を採用している。