■

テストケースがテストケース用のdiconファイルに依存するのは問題ないんじゃない。

伝わらなかった模様なのでサンプル付き

class hoge {
　private final static String PATH="hoge.dicon";
　private static S2Container container = S2ContainerFactory.create(PATH);
：

こんなクラスを書いたんです。そしたら、テストケースでもPATHに依存するなぁと・・・で、最終版はこんな感じになりました。カプセルのちょっとした破壊(^^;

protected static String PATH="hoge.dicon";

これで出来るかどうかは今日中に判ります(笑)
（追記）(~ヘ~;)ウーン
class hogeAImpl implements hogeA・・・
class hogeBImpl implements hogeB・・・
の両方がhoge.diconを使ってます
hogeBImplは通信するプログラムなのでテストしやすさを考えて
class hogeBDummy implements hogeB・・・
を作る事にしました。
テストケースを作っているのはhogeAImplに対してです。
hogeAImplはhogeBをダイコンに注入してもらっているので、テスト時にはhoge.diconをテスト用のhogetest.diconに切り替える必要があります。
もしかしてこのアプローチが間違い？
（追記）
hogeAImplとテストケースのコンテナって別のオブジェクトになるんだね〜どうしよ・・・ことごとく失敗中(T.T)
（追記）一応解消
hogeAImplにgetHogeBを追加。
コンストラクタでhogeBとコンテナをsingleton生成するように書き換え。
diconのファイル名をダイコンから受け取れるようにコンストラクタを追加。

hogeAImpl() {
this(PATH);
}
hogeAImpl(String dicon) {
if(hogeB==null) {
container = S2ContainerFactory.create(dicon);
hogeB = (SenderService)container.getComponent("hogeB");
}

テストケースではhogetest.diconをincludeしてダイコンにhogeAを作らせて、テストケースではhogeBDummyをgetしてassertXXXXで使う
diconの依存性注入をするダイコンが必要になって、そのダイコンの依存性を・・・って状態に行くことなくとりあえず解消して良かった（違
この問題って結局どこかで依存性が必要になるけどそれをどれだけ後から注入出来るかって言うところに行くのかなぁ〜それともそもそも間違えてる？
（追記）
ひがさんのサンプルを見ながらほとんどそのまま実装(^^;
setContainerって誰が呼び出すの！？っていう疑問をよそにとりあえずテストケースを走らせてみる・・・w(゜o゜)w オオ-
エラーなしでさくっと終了しました。
ってことでとりあえずブレークポイントを置いて・・・実行！
initで動いているんだ〜へ〜
有る意味この機能は恐ろしいです。もうちょっと使ってから色々考える事にしよう(^^;
（追記）
とりあえずコンストラクタの引数で使ってみた・・・ばっちり動いてる(^^;
（追記）
調子に乗って色々実験
感想：マジっすか！？
これが出来るって事はもしかしてこんなこと出来るのかなぁ〜ってノリで試したやつが全部あっさりと出来ちゃったよ(^^;
あ〜どんどんS2に浸食されていく〜(笑)