C # "interner" Zugriffsmodifikator beim Testen von Einheiten

Ich bin neu im Unit-Test und versuche herauszufinden, ob ich mehr 'internen' Zugriffsmodifikator verwenden soll. Ich weiß, dass wir, wenn wir 'internal' verwenden und die Assemblyvariable 'InternalsVisibleTo' setzen, Funktionen testen können, die wir aus dem Testprojekt nicht als öffentlich deklarieren möchten. Dies lässt mich denken, dass ich einfach immer 'intern' verwenden sollte, da mindestens jedes Projekt (sollte?) Ein eigenes Testprojekt hat. Könnt ihr mir einen Grund nennen, warum ich das nicht tun sollte? Wann sollte ich "privat" verwenden?

Interne Klassen müssen getestet werden und es gibt ein Assemby-Attribut:

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("MyTests")]

Fügen Sie dies der Projektinfodatei hinzu, z Properties\AssemblyInfo.cs .

Wenn Sie private Methoden testen möchten, schauen Sie sich PrivateObjectund PrivateTypein der anMicrosoft.VisualStudio.TestTools.UnitTesting Namespace. Sie bieten einfach zu verwendende Wrapper um den erforderlichen Reflektionscode.

Dokumente : PrivateType , PrivateObject

Für VS2017 und 2019 finden Sie diese, indem Sie das Nuget MSTest.TestFramework herunterladen

Zusätzlich zu Erics Antwort können Sie dies auch in der csprojDatei konfigurieren :

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

Wenn Sie pro zu testendem Projekt ein Testprojekt haben, können Sie in Ihrer Directory.Build.propsDatei Folgendes tun :

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

Siehe: https://stackoverflow.com/a/49978185/1678053
Beispiel: https://github.com/gldraphael/evlog/blob/master/Directory.Build.props#L5-L12

Verwenden Sie standardmäßig weiterhin privat. Wenn ein Mitglied nicht über diesen Typ hinaus verfügbar gemacht werden soll, sollte es nicht über diesen Typ hinaus verfügbar gemacht werden, auch nicht innerhalb desselben Projekts. Dies hält die Dinge sicherer und aufgeräumter - wenn Sie das Objekt verwenden, ist klarer, welche Methoden Sie verwenden sollen.

Trotzdem halte ich es manchmal für sinnvoll, natürlich-private Methoden zu Testzwecken intern zu machen. Ich ziehe das der Verwendung von Reflexion vor, die refactoring-unfreundlich ist.

Eine zu berücksichtigende Sache könnte ein "ForTest" -Suffix sein:

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

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

Wenn Sie dann die Klasse innerhalb desselben Projekts verwenden, ist es (jetzt und in Zukunft) offensichtlich, dass Sie diese Methode nicht wirklich verwenden sollten - sie dient nur zu Testzwecken. Das ist ein bisschen hackig und nicht etwas, das ich selbst mache, aber es ist zumindest eine Überlegung wert.

Sie können auch private Methoden verwenden und private Methoden mit Reflektion aufrufen. Wenn Sie Visual Studio Team Suite verwenden, verfügt es über einige nette Funktionen, die einen Proxy generieren, um Ihre privaten Methoden für Sie aufzurufen. Hier ist ein Code-Projektartikel, der zeigt, wie Sie die Arbeit selbst erledigen können, um private und geschützte Methoden zu testen:

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

In Bezug auf den Zugriffsmodifikator, den Sie verwenden sollten, lautet meine allgemeine Faustregel: Beginnen Sie mit privat und eskalieren Sie nach Bedarf. Auf diese Weise legen Sie so wenig interne Details Ihrer Klasse offen, wie wirklich benötigt werden, und es hilft, die Implementierungsdetails so zu verbergen, wie sie sein sollten.

Ich benutze Dotnet 3.1.101und die .csprojErgänzungen, die für mich arbeiteten, waren:

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

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

Hoffe das hilft jemandem da draußen!