C # „wewnętrzny” modyfikator dostępu podczas wykonywania testów jednostkowych

Jestem nowy w testowaniu jednostkowym i staram się dowiedzieć, czy powinienem zacząć używać więcej „wewnętrznego” modyfikatora dostępu. Wiem, że jeśli użyjemy „wewnętrznego” i ustawimy zmienną asemblerową „InternalsVisibleTo”, możemy przetestować funkcje, których nie chcemy ogłaszać publicznie z projektu testowego. To sprawia, że ​​myślę, że zawsze powinienem używać „wewnętrznego”, ponieważ przynajmniej każdy projekt (powinien?) Ma swój własny projekt testowy. Czy możecie mi powiedzieć, dlaczego nie powinienem tego robić? Kiedy powinienem używać „prywatnego”?

Klasy wewnętrzne muszą zostać przetestowane, a istnieje atrybut assemby:

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("MyTests")]

Dodaj to do pliku informacji o projekcie, np Properties\AssemblyInfo.cs.

Jeśli chcesz przetestować metody prywatne, przyjrzeć się PrivateObjecti PrivateTypew Microsoft.VisualStudio.TestTools.UnitTestingprzestrzeni nazw. Oferują łatwe w użyciu opakowania wokół niezbędnego kodu odbicia.

Dokumenty: PrivateType , PrivateObject

W przypadku wersji VS2017 i 2019 można je znaleźć, pobierając nuget MSTest.TestFramework

Dodając do odpowiedzi Erica, możesz również skonfigurować to w csprojpliku:

<ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>MyTests</_Parameter1>
    </AssemblyAttribute>
</ItemGroup>

Lub jeśli masz jeden projekt testowy na projekt do przetestowania, możesz zrobić coś takiego w swoim Directory.Build.propspliku:

<ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>$(MSBuildProjectName).Test</_Parameter1>
    </AssemblyAttribute>
</ItemGroup>

Zobacz: https://stackoverflow.com/a/49978185/1678053
Przykład: https://github.com/gldraphael/evlog/blob/master/Directory.Build.props#L5-L12

Domyślnie używaj prywatnego. Jeśli członek nie powinien być narażony poza ten typ, nie powinien być narażony poza ten typ, nawet w ramach tego samego projektu. Dzięki temu wszystko jest bezpieczniejsze i bardziej uporządkowane - gdy używasz obiektu, jest bardziej jasne, z jakich metod możesz korzystać.

To powiedziawszy, myślę, że czasem rozsądne jest uczynienie metod naturalnie prywatnych wewnętrznymi dla celów testowych. Wolę to od użycia refleksji, która jest nieprzyjazna dla refaktoryzacji.

Jedną rzeczą do rozważenia może być sufiks „ForTest”:

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

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

Następnie, gdy korzystasz z klasy w ramach tego samego projektu, oczywiste jest (teraz iw przyszłości), że tak naprawdę nie powinieneś używać tej metody - jest ona dostępna tylko w celach testowych. Jest to trochę zuchwałe i nie robię tego sam, ale przynajmniej warto to rozważyć.

Możesz także użyć prywatnego i możesz wywoływać prywatne metody z refleksją. Jeśli korzystasz z Visual Studio Team Suite, ma on fajną funkcjonalność, która wygeneruje serwer proxy do wywołania twoich prywatnych metod. Oto artykuł dotyczący projektu kodu, który pokazuje, jak możesz sam wykonać pracę, aby przetestować metody prywatne i chronione:

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

Pod względem tego, jakiego modyfikatora dostępu należy użyć, moja ogólna zasada zaczyna się od prywatnego i eskaluje w razie potrzeby. W ten sposób ujawnisz tak mało wewnętrznych szczegółów swojej klasy, jakie są naprawdę potrzebne, i pomaga ukryć szczegóły implementacji, tak jak powinny.

Używam Dotnet 3.1.101i .csprojdodatki, które działały dla mnie były:

<PropertyGroup>
  <!-- Explicitly generate Assembly Info -->
  <GenerateAssemblyInfo>true</GenerateAssemblyInfo>
</PropertyGroup>

<ItemGroup>
  <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleToAttribute">
  <_Parameter1>MyProject.Tests</_Parameter1>
  </AssemblyAttribute>
</ItemGroup>

Mam nadzieję, że to pomoże komuś tam!