Jak utworzyć interfejs, który zachowuje niektóre metody wewnętrzne do testowania w języku C#?

Question

Rozważmy następujące klasy

public class Entity { 
    public void Foo() { ... } 
    internal void Bar() { ... } 
} 

Jak widać ma public sposób i metodę internal. Teraz chciałbym stworzyć interfejs, który pozwoli mi naśmiewać się z tej klasy w testach (zarówno w tym zespole, jak iw innych). Przepisuję mój kod w następujący sposób:

public interface IEntity { 
    void Foo(); 
} 

internal class Entity : IEntity { 
    public void Foo() { ... } 
    public void Bar() { ... } 
} 

Jednak tworzy to kolejny problem. Przy użyciu klasy w inny sposób, w tym samym zespole nie mogę nazwać Bar już:

public class OtherClass { 
    public void SomeMethod(IEntity entity) { 
    entity.Bar(); // error! 
    } 
} 

Przepisanie kodu tak:

public class OtherClass { 
    public void SomeMethod(IEntity entity) { 
    (entity as Entity).Bar(); // error in test! 
    } 
} 

spowoduje błąd w badanej jednostki, która wyzwala SomeMethod . Jak przerobić mój kod, aby nadal korzystać z metod internal w tym samym asemblowaniu, a jedynie wystawiać publicznych członków na inne zespoły?

Aktualizacja: Klasa OtherClass jest klasą narzędzie, które musi działać na wewnętrzne klasy Entity, które nie są narażone na użytkowników bezpośrednio. Jednak sama ta klasa jest narażona na działanie użytkowników, więc pośrednio mają dostęp do wewnętrznych elementów urządzenia Entity. Jest to pożądane, ponieważ SomeMethod przeprowadzi niezbędne kontrole w celu upewnienia się, że użytkownicy nie zepsują stanu wewnętrznego obiektu Entity.

Answer 1

Zmieniano:

Rozszerzenie interfejsu IEntity z wewnętrznym interfejsem ITestEntity do testowania:

public interface IEntity 
{ 
    //Implementation 

} 

internal interface ITestEntity : IEntity 
{ 
    void TestMethod(); 
} 


class Entity: ITestEntity 
{ 
    // 
} 

Answer 2

Zakładam, że chcesz wywołać metodę wewnętrzną tylko w swoich testach jednostkowych, prawda? W przeciwnym razie eksponowanie metody na inne złożenia wymagałoby zastąpienia wewnętrznego z publiczną przyczyną.

W przypadku testów jednostkowych ogólnie rzecz biorąc, zawsze jest dobry wzór, jeśli NIE testujesz metod prywatnych lub wewnętrznych. Test jednostkowy powinien po prostu przetestować interfejs publiczny, a każda klasa biznesowa powinna zapewnić publiczne metody, które robią wszystko wewnętrznie ... Aby przetestować swoje wewnętrzne metody, musiałbyś przetestować publiczną reprezentację tego.

Ale tak. Jeśli chcesz przetestować prywatny lub wewnętrzny akcesor, projekty Visual Studio Test zwykle mogą wygenerować dla Ciebie wrappery. Będziesz musiał zadzwonić do ctor dostępowego zamiast normalnego ctor klasy. Gdy to zrobisz, uzyskasz dostęp do prywatnych lub wewnętrznych metod/właściwości tej instancji.

Znajdź więcej informacji na temat tych generowanych typów tutaj: http://msdn.microsoft.com/en-us/library/bb385974(v=vs.100).aspx

: Edit: po dyskusji, mam dla was przykładem, w jaki sposób korzystać z MOQ razem z Unity i UnityAutoMoq (3 różni Nugets). Powiedzmy klasa wygląda następująco:

public class MyClassWithInternalMethod 
{ 
    internal object GetSomething() 
    { 
     return null; 
    } 
} 

Aby to sprawdzić można drwić go tak:

using (var moqUnityContainer = new UnityAutoMoqContainer()) 
{ 
    moqUnityContainer.GetMock<MyClassWithInternalMethod>().Setup(p => p.GetSomething()).Returns(null); 
} 

Answer 3

Jak przerobić mój kod, aby nadal używać wewnętrznych metod w tym samym zespole, a jednocześnie tylko wystawiać publicznych członków na inne zespoły?

Wykonaj interfejs wewnętrzny, a następnie jawnie go zaimplementuj.

internal interface ITest 
{ 
    void Foo(); 
    void Bar(); 
} 

public class Thing : ITest 
{ 
    void ITest.Foo() { this.Foo(); } 
    void ITest.Bar() { this.Bar(); } 
    public Foo() { ... } 
    internal Bar() { ... } 
} 

Więc teraz publicznej klasy Thing ma tylko jedną metodę publiczną Foo. Kod spoza zestawu nie może wywoływać ani bezpośrednio, ani poprzez konwersję do interfejsu, ponieważ zarówno Bar, jak i ITest są wewnętrznymi.

Zauważam, że klasa podstawowa podstawowa klasa musi być co najmniej tak widoczna, jak klasa pochodna. Nie takie interfejsy. Niewiele osób wie, że to jest legalne:

class C : C.I 
{ 
    private interface I {} 
} 

klasa może implementować interfejs, który tylko może widzieć! To trochę dziwna rzecz, ale są sytuacje, w których ma to sens.