12:54僕はユニットテストコードをテスト対象プロジェクトとは別のプロジェクトに用意する派だ。理由は、同一プロジェクトに格納するとリリース時にそれらを除外しなければならないから。一回そういうスクリプト書いてしまえば使い回しが利くだろうし、これ以外に大した理由はない。さんは、僕とは違い同一プロジェクトに含める派で、除外するための手間を逆手に取っている。予定は未定Blog版なるほど、確かにそういう考え方もできる。同一プロジェクトに含む場合、テスト対象とテストの距離が近くなるなど、他にもメリットがあるのだと思う。所で、最近僕はそもそも同一プロジェクトに含んだとしてもテストコードを除外する必要はないのではないかと疑問に感じている。テストコードが含まれていることで何かしらの不都合が生じることなんてないのではなかろうか。言うならアセンブリのファイルサイズが若干大きくなることくらいか、と。ビルドツールの強制というメリットがなくなるという点。一見するとデメリットだ。テストコードを除外することに本質的な意味がないのであれば、ビルドツールの強制のためだけにテストコード除外というプロセスを組み込むことになってしまう。突き詰めればそれはビルドツールを使えと単に指示することと変りないことになる。テストコードを除外する必要がないのだから。テストコードが含まれていても不都合が本当に生じないのかどうかはわからない。実際に試してみる必要もありそうだ。開発時にはそういった縛りがないため、ビルド時に除外してしまえばいいか、と。]なるほど、それは除外せざるを得ないですね。ちなみに、「バグがないプログラムのつくり方」という書籍でもやはり同一プロジェクトに配置してビルド時に除外することを推奨してました。テスト対象のコードと同じ場所に置くか、テスト用のパッケージ・フォルダを作るかで分けて記述してありました。賛否両論ある、とした上で、TDDを徹底させるためにはテストとテスト対象は同じ場所に置くべき、という考えのようです。ビルド時に除外する、というのは同じでも、この本の著者は物理的にも同じ場所に置くことを推奨しているのですね。JavaではEclipseを使っている身としては、「パッケージは同じだけれどフォルダを分ける」ことが多いです。ビルド時に除外する、というのは同じでも、この本の著者は物理的にも同じ場所に置くことを推奨しているのですね。僕が今やってる開発ではこれを採用してみました。ファイル名を普通に付けてしまうと、Hoge.csHogeFactory.csHogeFactoryTest.csHogeTest.csって感じに順番が変になる場合があるので、Hoge.csHoge.Test.csHogeFactory.csHogeFactory.Test.csてな感じで名前付けしてます。29ブログ内検索カウンターアクセスカウンターおすすめプロフィールAuthor:よこけん性別は男です。生年月日は1984年2月頃です。社会人は2004年4月頃からやってます。C#は2004年10月頃からやってます。このブログは2006年7月頃からやってます。アプリケーションリンクopus-i商用可・加工可で、綺麗な素材を提供していらっしゃいます。紹介していらっしゃいます。中心に扱っていらっしゃいます。コマンドレットをまとめたスナップインです。クラスライブラリを作ってみました。最近の記事ブログ移転しました。返事を返せない場合があります。