Modyfikator dostępu C # "internal" podczas wykonywania testów jednostkowych

Jeśli chcesz przetestować metody prywatne, spójrz na PrivateObject i PrivateType w przestrzeni nazw Microsoft.VisualStudio.TestTools.UnitTesting. Oferują one łatwe w użyciu owijki wokół niezbędnego kodu odbicia.

Docs: PrivateType, PrivateObject

Możesz również używać metod prywatnych i możesz wywoływać metody prywatne z reflection. Jeśli używasz pakietu Visual Studio Team Suite, ma on kilka ciekawych funkcji, które wygenerują serwer proxy, aby wywołać prywatne metody dla Ciebie. Oto artykuł projektu kodu, który pokazuje, jak możesz wykonać pracę samodzielnie, aby przetestować prywatne i chronione metody:

Http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx

W zakresie jakiego modyfikatora dostępu powinieneś użyć, mój ogólna zasada jest zacząć od prywatnych i eskalować w razie potrzeby. W ten sposób ujawnisz tak mało wewnętrznych szczegółów swojej klasy, jak są naprawdę potrzebne, a to pomaga utrzymać szczegóły implementacji w ukryciu, tak jak powinny być.

Domyślnie używaj opcji private. Jeśli członek nie powinien być wystawiony poza ten typ, nie powinien być wystawiony poza ten typ, nawet w ramach tego samego projektu. Dzięki temu rzeczy są bezpieczniejsze i bardziej uporządkowane - kiedy używasz obiektu, jaśniej jest, z jakich metod masz być w stanie korzystać.

Mimo tego, myślę, że rozsądne jest, aby metody naturalnie prywatne były czasami wewnętrzne dla celów testowych. Wolę to od używania refleksji, czyli refaktoryzacji-nieprzyjaznej.

One rzecz do rozważenia może być przyrostkiem "ForTest":

internal void DoThisForTest(string name)
{
    DoThis(name);
}

private void DoThis(string name)
{
    // Real implementation
}

Wtedy, gdy używasz klasy w ramach tego samego projektu, jest oczywiste (teraz i w przyszłości), że tak naprawdę nie powinieneś używać tej metody - jest tam tylko do celów testowych. To jest trochę chwiejne, i nie coś, co robię sam, ale to przynajmniej warte rozważenia.