2010-12-29 6 views
1

私は自分のプロジェクトの単体テストに取り組んでいます。 ビジネスロジックを持つDLLは.NET 2.0向けに構築する必要がありますが、テスト用にMoqを使用したいと思います(.NET 3.5が必要)。だからこそ、ビジネスロジックプロジェクトを参照して.Net 3.5プロジェクトをすべてのテストに分けて移動したのです。 私はテストプロジェクトから内部的なマークを付けたメソッドをテストする必要があります。私は条件付きビルドの記号で別のビルド構成を使用していることを行うための唯一の方法を見ることができます:UNITTESTSビルド設定のメソッドをpublicにします。

#if UNITTESTS 
public 
#else 
internal 
#endif 
int DoSomeAction(int param1, int param2) 
{ 
    // some logic that need to be tested here 
} 

が、コードのような種類が醜いです。おそらく、いくつかの特別な属性によるマーク方法のようなより良い方法があります。

[ConditionalPublic("UNITTESTS")] 
internal int DoSomeAction(int param1, int param2) 
{ 
    // some logic that need to be tested here 
} 

ありがとうございました。

答えて

7

あなたのプロジェクトassembly.csに(それがSystem.Runtime.CompilerServicesから来ている)

[assembly: InternalsVisibleTo("ProjectName.Tests")] 

属性を追加することができます。これで、テストプロジェクトは内部にアクセスできます。

HTH

+0

ああ、それは私が探しているものです!ありがとう! –

0

プライベートメソッドをテストしたくありません。プライベートとは、宣言するクラスだけがそれらについて知る必要があることを意味します。ユニットテストでさえそれにアクセスできる必要はありません。それはあなたがプライベートな部分をいつでも再設計できるという利点をもたらします。他のクラスはなく、単位テストさえ変更する必要はありません。パブリックメソッドのみをテストし、間接的にプライベートメソッドをテストします。それは私の意見です。

+0

しかし、内部アセンブリはローカルアセンブリに対してのみ公開されます。 – Simone

+0

まだ、私の意見では、単体テストは外部者(良い範囲を達成するためにいくつかの内部を知ることになる)の観点からでなければなりません。パブリックメソッドをテストする必要があります。あなたがそうするなら、非公開のものをテストする必要はありません。 – fejesjoco

+0

私はあなたに同意できません - ユニットテストはブラックボックステストではありません。 –

関連する問題