Modificatore di accesso "interno" C # quando si eseguono test di unità

Sono nuovo nel test unitario e sto cercando di capire se dovrei iniziare a utilizzare più modificatore di accesso "interno". So che se usiamo 'internal' e impostiamo la variabile di assembly 'InternalsVisibleTo', possiamo testare funzioni che non vogliamo dichiarare pubbliche dal progetto di testing. Questo mi fa pensare che dovrei sempre usare 'interno' perché almeno ogni progetto (dovrebbe?) Ha il proprio progetto di test. Ragazzi, potete dirmi un motivo per cui non dovrei farlo? Quando dovrei usare "privato"?

Le classi interne devono essere testate e c'è un attributo assembly:

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("MyTests")]

Aggiungi questo al file di informazioni del progetto, ad es Properties\AssemblyInfo.cs.

Se vuoi testare metodi privati, dai un'occhiata PrivateObjecte PrivateTypenello Microsoft.VisualStudio.TestTools.UnitTestingspazio dei nomi. Offrono wrapper di facile utilizzo attorno al codice di riflessione necessario.

Documenti: PrivateType , PrivateObject

Per VS2017 e 2019, puoi trovarli scaricando il nuget MSTest.TestFramework

Aggiungendo alla risposta di Eric, puoi anche configurarlo nel csprojfile:

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

O se hai un progetto di test per progetto da testare, potresti fare qualcosa del genere nel tuo Directory.Build.propsfile:

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

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

Continua a utilizzare privato per impostazione predefinita. Se un membro non deve essere esposto oltre quel tipo, non dovrebbe essere esposto oltre quel tipo, nemmeno all'interno dello stesso progetto. Ciò mantiene le cose più sicure e in ordine: quando si utilizza l'oggetto, è più chiaro quali metodi si intende essere in grado di utilizzare.

Detto questo, penso che sia ragionevole rendere i metodi naturalmente privati ​​interni a fini di test a volte. Preferisco usare la riflessione, che è refactoring-ostile.

Una cosa da considerare potrebbe essere un suffisso "ForTest":

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

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

Quindi quando stai usando la classe all'interno dello stesso progetto, è ovvio (ora e in futuro) che non dovresti davvero usare questo metodo - è lì solo a scopo di test. Questo è un po 'confuso, e non qualcosa che faccio da solo, ma è almeno degno di considerazione.

Puoi usare anche private e puoi chiamare metodi privati ​​con reflection. Se stai usando Visual Studio Team Suite ha delle belle funzionalità che genereranno un proxy per chiamare i tuoi metodi privati ​​per te. Ecco un articolo di progetto in codice che dimostra come è possibile eseguire autonomamente il lavoro per testare i metodi privati ​​e protetti:

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

In termini di quale modificatore di accesso dovresti usare, la mia regola generale è iniziare con privato ed intensificare secondo necessità. In questo modo esporrai tutti i dettagli interni della tua classe come sono realmente necessari e aiuta a mantenere nascosti i dettagli di implementazione, come dovrebbero essere.

Sto usando Dotnet 3.1.101e le .csprojaggiunte che hanno funzionato per me sono state:

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

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

Spero che questo aiuti qualcuno là fuori!