Codegenerierung, Kompilierung und Benennungskonventionen in Microsoft Fakes

In diesem Thema werden Optionen und Probleme bei der Fakes-Codegenerierung und Kompilierung und beschreibt die Namenskonventionen für Fakes-generierte Typen, Member und Parameter.

Anforderungen

• Visual Studio Ultimate

In diesem Thema

Hier ist, was Sie erfahren:

Code generation and compilation

• Konfigurieren der Codegenerierung der Stubs

• Typfilterung

• starke Namenssignierung

• Interne Typen

• Optimieren von Buildzeiten

• Avoiding Assembly Name Clashing

Fakes Naming Conventions

• Shim Type and Stub Type Naming Conventions

• Shim Delegate Property or Stub Delegate Field Naming Conventions

• Parameter Type Naming Conventions

• Recursive Rules

Codegenerierung und Kompilierung

Konfigurieren der Codegenerierung der Stubs

Die Generierung von Stubtypen wird in einer XML-Datei konfiguriert, die die FAKES-Dateierweiterung verfügt.Das Fakes-Framework integriert im Buildprozess durch benutzerdefinierte MSBuild-Aufgaben und erkennt diese Dateien zur Buildzeit.Der Fakes-Codegenerator kompiliert die Stubtypen in eine Assembly und fügt dem Projekt den Verweis hinzu.

Das folgende Beispiel veranschaulicht die Stubtypen, die in FileSystem.dll definiert werden:

<Fakes xmlns="https://schemas.microsoft.com/fakes/2011/">
    <Assembly Name="FileSystem"/>
</Fakes>

Typfilterung

Filter können in der FAKES-Datei festgelegt werden, um einzuschränken, die sollte gerodet werden eingibt.Sie können eine unbegrenzte Zahl im Normalfall hinzufügen, hinzufügen, entfernen Elemente unter dem StubGenerations-Element, um die Liste der ausgewählten Typen zu erstellen.

Beispielsweise generiert diese FAKES-Datei Stubs für Typen mit den System- und System.IO-Namespaces, aber enthält einen Typ aus, der "Handle" im System enthält:

<Fakes xmlns="https://schemas.microsoft.com/fakes/2011/">
  <Assembly Name="mscorlib" />
  <!-- user code -->
  <StubGeneration>
    <Clear />
    <Add Namespace="System!" />
    <Add Namespace="System.IO!"/>
    <Remove TypeName="Handle" />
  </StubGeneration>
  <!-- /user code -->
</Fakes>

Die Filterzeichenfolgen verwenden eine einfache Grammatik, um zu definieren, wie die Suche ausgeführt werden soll:

• Filter sind standardmäßig die Groß-/Kleinschreibung nicht beachtet; Filter übergeben ein Teilzeichenfolgenabgleichen aus:

  el entspricht "Hello" ab

• Das Hinzufügen von ! am Ende des Filters macht es eine präzise die Groß- und Kleinschreibung beachtet:

  el! stimmt nicht "Hello" ab

  hello! entspricht "Hello" ab

• Das Hinzufügen von * am Ende des Filters können Sie das Präfix der Zeichenfolge übereinstimmen:

  el* stimmt nicht "Hello" ab

  he* entspricht "Hello" ab

• Mehrere Filter in einer durch Semikolons getrennte Liste werden als Trennung kombiniert:

  el;wo entspricht "Hello" und "Welt" ab

Rodende konkrete Klassen und virtuelle Methoden

Standardmäßig werden Stubtypen für alle nicht versiegelte Klassen generiert.Es ist möglich, die Stubtypen zu den abstrakten Klassen durch die .fakes-Konfigurationsdatei einzuschränken:

<Fakes xmlns="https://schemas.microsoft.com/fakes/2011/">
  <Assembly Name="mscorlib" />
  <!-- user code -->
  <StubGeneration>
    <Types>
      <Clear />
      <Add AbstractClasses="true"/>
    </Types>
  </StubGeneration>
  <!-- /user code -->
</Fakes>

starke Namenssignierung

Das Fakes-Framework signiert automatisch die generierte Fakes-Assembly, wenn die Assembly ausgeglichene stark signiert wird.Das FakesFramework verwendet immer die gleiche Schlüssel, es sei denn, der Benutzer einen anderen Schlüssel angibt, um die Assembly zu signieren.Eine andere Schlüssel kann in der FAKES-Datei angegeben werden.

<Fakes ...>
  <Compilation KeyFile="path to the key file" />
</Fakes>

Interne Typen

Der Fakes-Codegenerator generiert Shimtypen und erstellt einen Stub für Typen für Typen, die zur generierten Fakes-Assembly sichtbar sind.So interne Typen Sie sichtbar zu machen kann ein InternalsVisibleTo-Attribut der ausgeglichenen Assembly hinzufügen die der generierten Fakes-Assembly Sichtbarkeit gibt.

[assembly: InternalsVisibleTo("FileSystem.Fakes")]

Wenn die Assembly ausgeglichene stark signiert ist signiert, das Fakes-Framework automatisch stark die generierte Fakes-Assembly.In diesem Fall muss das InternalsVisibleToAttribute-Attribut den Assemblynamen und den öffentlichen Schlüssel verweisen.Das Fakes-Framework verwendet immer die gleiche Schlüssel, um die Assembly zu signieren, erstellen Sie diesen Ausschnitt als Ausgangspunkt, um InternalsVisibleTo-Attribut dem Projekt hinzuzufügen.

[assembly: InternalsVisibleTo("FileSystem.Fakes, PublicKey=0024000004800000940000000602000000240000525341310004000001000100e92decb949446f688ab9f6973436c535bf50acd1fd580495aae3f875aa4e4f663ca77908c63b7f0996977cb98fcfdb35e05aa2c842002703cad835473caac5ef14107e3a7fae01120a96558785f48319f66daabc862872b2c53f5ac11fa335c0165e202b4c011334c7bc8f4c4e570cf255190f4e3e2cbc9137ca57cb687947bc")]

Optimieren von Buildzeiten

Die Kompilierung von Fakes-Assemblys kann die Erstellungszeit erheblich steigern.Sie können die Buildzeit minimieren, indem Sie die Fakes-Assemblys für .NET-Systemassemblys und Assemblys von Drittanbietern in einem separaten Projekt zentralen generieren.Da diese Assemblys selten auf dem Computer ändern, können Sie die generierten Fakes-Assemblys in anderen Projekten wiederverwenden.

Von den Komponententestprojekten können Sie einen Verweis auf den kompilierten Fakes-Assemblys einfach erstellen, die unter dem FakesAssemblies im Projektordner platziert werden.

1. Erstellen Sie eine neue Klassenbibliothek mit der .NET-Laufzeit-Version erstellt, die die Testprojekte übereinstimmt.Fügen wir sie aufrufen Fakes.Prebuild.Entfernen Sie die class1.cs-Datei aus dem Projekt, nicht benötigt.

2. Fügen Sie Verweis auf alle System- und Drittanbieterassemblys hinzu, die Sie Fakes für erfordern.

3. Fügen Sie eine FAKES-Datei für jeden der Assembly und des Build hinzu.

4. Klicken Sie im Testprojekt fügen Sie einen Assemblyverweis hinzu und navigieren Sie zum Ordner Fakes.Prebuild\FakesAssemblies und suchen Sie die entsprechende Assembly.

Vermeiden von Assemblynamenzusammenstoßens

In einer Team Build-Umgebung werden alle Buildausgaben in ein Verzeichnis zusammengeführt.Bei der Verwendung von Fakes durch mehrere Projekte könnte es vorkommen, dass sich Fakes-Assemblys von unterschiedlichen Version überschreiben.Beispielsweise würden TestProject1 fakes mscorlib.dll aus .NET Framework 2.0 und TestProject2 fakes mscorlib.dll für .NET Framework 4 beide zu einer mscorlib.Fakes.dll-Fakes-Assembly führen.

Um dieses Problem zu vermeiden, sollte Fakes beim Hinzufügen der FAKES-Dateien automatisch versionsqualifizierte Fakes-Assemblynamen für Nicht-Projektverweise erstellen.Ein Version-qualifizierter Fakes-Assemblyname bettet eine Versionsnummer ein, wenn Sie den Fakes-Assemblynamen erstellen:

Eine Assembly MyAssembly und eine Version 1.2.3.4 angegeben, ist der Fakes-Assemblyname MyAssembly.1.2.3.4.Fakes.

Sie können diese Version durch die Bearbeitung ändern oder entfernen das Versionsattribut des Assemblyelements im .fakes:

attribute of the Assembly element in the .fakes:
<Fakes ...>
  <Assembly Name="MyAssembly" Version="1.2.3.4" />
  ...
</Fakes>

Fälscht Namenskonventionen

Shimtyp und -Stub geben Namenskonventionen ein

Namespaces

• Das Suffix .Fakes wird dem Namespace hinzugefügt.

  Beispielsweise enthält System.Fakes-Namespace die Shimtypen des System-Namespace.

• Global.Fakes enthält den Shimtyp des leeren Namespace.

Typnamen

• Shimpräfix wird dem Typnamen hinzugefügt, um den Shimtypnamen zu erstellen.

  Beispielsweise ist ShimExample der Shimtyp des Beispielstyps.

• Stubpräfix wird dem Typnamen hinzugefügt, um den Stubtypnamen zu erstellen.

  Beispielsweise ist StubIExample der Stubtyp des IExample-Typs.

Typargumente und Strukturen des geschachtelten Typs

• Generische Typargumente werden kopiert.

• Struktur des geschachtelten Typs wird für Shimtypen kopiert.

Entsprechung für Delegateigenschaft aus oder roden Sie Delegatfeldnamenskonventionen

Grundlegende Regeln für Feldnamen, beginnend mit einem leeren Titel ab:

• Der Methodenname wird angefügt.

• Wenn der Methodenname eine explizite Schnittstellenimplementierung ist, werden die Punkte entfernt.

• Wenn die Methode generisch ist, wird Ofn angefügt, wo n die Anzahl der generischen Methodenargumenten ist.

Besondere Methodennamen wie Eigenschaftgetter oder Setter behandelt werden, wie in der folgenden Tabelle beschrieben.

Hinweise

• get-Accessor und Setter von Indexern werden ähnlich der Eigenschaft behandelt.Der Standardname für einen Indexer ist Item.

• Parametertyp Namen werden umgewandelt und verkettet.

• Rückgabetyp wird ignoriert, es sei denn, es eine Überladungsmehrdeutigkeit gibt.Wenn dies der Fall ist, wird der Rückgabetyp am Ende des Namens angehängt

Parametertypnamenskonventionen

Rekursive Regeln

Die folgenden Regeln werden rekursiv angewendet:

• Da Fakes C# verwendet, um die Fakes-Assemblys zu generieren, wird jedes Zeichen, das ein ungültiges C#-Token erzeugt werden würde, auf "_" mit Escapezeichen versehen (Unterstrich).

• Wenn ein resultierender Name mit einem Mitglied des deklarierenden Typs verursacht, wird ein Nummerierungsschema verwendet, indem einen zweistelligen Indikator angefügt und bei 01 beginnt.

Externe Ressourcen

Empfehlungen

Tests für fortlaufende Übermittlung mit Visual Studio 2012 - Chapter 2: Komponententest: Testen des Inneres

Siehe auch

Konzepte

Isolieren von getestetem Code mithilfe von Microsoft Fakes