Konwencje dotyczące generowania, kompilowania i nazywania w Microsoft Fakes

W tym temacie omówiono opcje i kwestie generowania i kompilacji pozornego kodu i opisano konwencje nazewnictwa dla typów, elementów członkowskich i parametrów pozornie wygenerowanych.

Wymagania

• Visual Studio Ultimate •

W tym temacie

Generowanie i kompilacja kodu

• Konfiguruj generowanie kodu dla fragmentów • Filtrowanie typu • Tworzenie namiastek dla klas konkretnych i metod wirtualnych • Typy wewnętrzne • Optymalizowanie czasu kompilacji • Unikanie konfliktu nazw zestawów

Konwencje nazewnictwa substytutów

• Konwencje nazewnictwa typów shim i typów stub • Konwencje nazewnictwa właściwości delegatów shim i pól delegatów stub • Konwencje nazewnictwa typów parametrów • Reguły cykliczne

Zasoby zewnętrzne

• Wskazówki

Generowanie i kompilacja kodu

Konfigurowanie generowania kodu odcinków

Generowanie typów namiastek można skonfigurować w pliku XML, który posiada rozszerzenie .fakes.Fakes Framework integruje się w procesie kompilacji przez własne zadania MSBuild i wykrywa te pliki w czasie kompilacji.Generator kodu pozornego kompiluje typy namiastek w zestaw i dodaje referencję do projektu.

Poniższy przykład ilustruje typy namiastki zdefiniowane w FileSystem.dll:

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

Filtrowanie typów

W pliku .fakes można ustawić filtry, aby ograniczyć typy dla których mają być generowane namiastki.Możesz dodać nieograniczoną liczbę elementów Clear, Add, Remove do elementu StubGeneration, aby zbudować listę wybranych typów.

Na przykład, ten plik .fakes generuje namiastki dla typów w przestrzeni nazw System i System.IO, z wyłączeniem wszystkich typów zawierających "Handle" w przestrzeni System:

<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>

Ciągi filtrów używają prostej gramatyki do zdefiniowania dopasowania:

• Domyślnie wielkość liter w filtrach nie ma znaczenia; filtry dopasowują podciąg:

  el pasuje do "hello"

• Dodanie ! do końca filtru uczyni go precyzyjnym i czułym na wielkość liter:

  el! nie pasuje do "hello"

  hello! pasuje do "hello"

• Dodanie * do końca filtru uczyni go pasującym do przedrostka:

  el* nie pasuje do "hello"

  he* pasuje do "hello"

• Wiele filtrów na rozdzielonej średnikami liście zostanie połączonych jako alternatywa:

  el;wo pasuje do "hello" i "world"

Tworzenie namiastek dla klas konkretnych i metod wirtualnych

Domyślnie, typy namiastki są generowane dla wszystkich niezamkniętych klas.Możliwe jest ograniczenie typów namiastki do konkretnych klas abstrakcyjnych za pomocą pliku konfiguracji .fakes:

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

Typy wewnętrzne

Generator kodu pozornego wygeneruje typy zastępcze i typy namiastki dla typów widocznych dla wygenerowanego zestawu pozornego.Aby typy wewnętrzne zestawu typu shim były widoczne dla zestawów Fakes i Test, dodaj atrybuty InternalsVisibleToAttribute do kodu zestawu typu shim, który zwiększa widoczność w wygenerowanych zestawach Fakes i Test.Oto przykład:

// FileSystem\AssemblyInfo.cs
[assembly: InternalsVisibleTo("FileSystem.Fakes")]
[assembly: InternalsVisibleTo("FileSystem.Tests")]

Typy wewnętrzne w zestawach o silnej nazwie

Jeśli zestawu obsługiwanego za pośrednictwem poprawek zgodności aplikacji ma silną nazwę i chcesz mieć dostęp do wewnętrznych typów zestawu:

• Zestaw testowy i zestaw pozorowany muszą posiadać silne nazwy.

• Należy dodać klucze publiczne testu i podrobionego zestawu do atrybutów InternalsVisibleToAttribute w zestawach typu shim.Oto jak nasze przykładowe atrybuty w kodzie zestawu obsługiwanego za pośrednictwem poprawek zgodności aplikacji wyglądałby po ustawieniu silnej nazwy dla tego zestawu:

  // FileSystem\AssemblyInfo.cs
  [assembly: InternalsVisibleTo("FileSystem.Fakes",
      PublicKey=<Fakes_assembly_public_key>)]
  [assembly: InternalsVisibleTo("FileSystem.Tests",
      PublicKey=<Test_assembly_public_key>)]
  

Framework Fakes automatycznie nada silną nazwę wygenerowanemu zestawowi substytowanemu, jeśli zestaw zastępczy posiada silną nazwę.Musisz wykonać silny podpis zestawu testowego.Zobacz Tworzenie i używanie zestawów o silnej nazwie.

Struktura Fakes używa tego samego klucza do podpisywania wszystkich generowanych zestawów, więc tego fragmentu kodu można użyć jako punktu wyjścia, aby dodać atrybut InternalsVisibleTo dla zestawu substytuowanego do kodu zestawu typu shim.

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

Można określić inny klucz publiczny zestawu pozorowanego, taki jak klucz utworzony dla zestawu typu shim, podając pełną ścieżkę do pliku .snk, który zawiera klucz alternatywny jako wartość atrybutu KeyFile w elemencie Fakes\Compilation pliku .fakes.Na przykład:

<-- FileSystem.Fakes.fakes -->
<Fakes ...>
  <Compilation KeyFile="full_path_to_the_alternate_snk_file" />
</Fakes>

Następnie musisz użyć klucza publicznego pliku zastępczego .snk jako drugiego parametru atrybutu InternalVisibleTo do zestawu pozorowanego w kodzie zestawu shimmed:

// FileSystem\AssemblyInfo.cs
[assembly: InternalsVisibleTo("FileSystem.Fakes",
    PublicKey=<Alternate_public_key>)]
[assembly: InternalsVisibleTo("FileSystem.Tests",
    PublicKey=<Test_assembly_public_key>)]

W przykładzie powyżej wartości Alternate_public_key i Test_assembly_public_key może być taki sam.

Optymalizacja czasów kompilacji

Kompilacja zestawów pozornych może znacznie zwiększyć czas kompilacji.Generując zestawy pozorne dla zestawów .NET System i zestawów innych firm w osobnym scentralizowanym projekcie możesz zminimalizować czas kompilacji.Ponieważ takie zestawy rzadko się zmieniają, można użyć ponownie wygenerowanych zestawów pozornych w innych projektach.

Z projektów testów jednostkowych można po prostu wziąć referencję do skompilowanych zestawów pozornych, które są umieszczone w FakesAssemblies w folderze projektu.

1. Utwórz nową bibliotekę klas z wersją środowiska wykonawczego .NET pasującą do Twoich projektów testów.Nazwijmy ją Fakes.Prebuild.Usuń plik class1.cs z projektu, nie jest potrzebny.

2. Dodaj odwołanie do wszystkich zestawów System i innych firm, dla których potrzebujesz substytutów.

3. Dodaj plik .fakes do każdego zestawu i skompiluj projekt.

4. Z projektu testu

   • Upewnij się, że masz odwołanie do środowiska uruchomieniowego Podrobionych DLL:

     C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.QualityTools.Testing.Fakes.dll

   • Dla każdego zestawu, dla którego utworzono substytuty, dodaj odwołanie do odpowiedniego pliku DLL w folderze Fakes.Prebuild\FakesAssemblies projektu.

Unikanie konfliktu nazw zestawów

W środowisku kompilacji zespołowej wszystkie dane wyjściowe kompilacji są scalane w jeden katalog.W przypadku, gdy wiele projektów używa substytutów, może się zdarzyć, że zestawy pozorne z różnych wersji nadpiszą się.Na przykład substytut mscorlib.dll z TestProject1 z .NET Framework 2.0 i substytut mscorlib.dll z TestProject2 z .NET Framework 4, oba przekażą zestaw pozorowany mscorlib.Fakes.dll

Aby uniknąć tego problemu, substytuty powinny automatycznie tworzyć nazwy zestawów pozorowanych z wersją kwalifikowaną dla odwołań nie będących odwołaniami projektu podczas dodawania plików .fakes.Nazwa zestawu pozorowanego z wersją kwalifikowaną dołącza numer wersji, podczas tworzenia nazwy zestawu pozorowanego:

Biorąc pod uwagę zestaw MyAssembly i wersję 1.2.3.4 nazwa zestawu pozorowanego to MyAssembly.1.2.3.4.Fakes.

Możesz zmienić lub usunąć tę wersję przez edycję atrybutu Wersja elementu Zestaw w .fakes:

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

Konwencje nazewnictwa substytutów

Konwencje nazewnictwa typów zastępczych i typów namiastek

Przestrzenie nazw

• Do przestrzeni nazw jest dodawany sufiks .fakes.

  Na przykład, przestrzeń nazw System.Fakes zawiera typy zastępcze z przestrzeni nazw System.

• Global.Fakes zawiera typ zastępczy pustej przestrzeni nazw.

Nazwy typów

• Przedrostek Shim jest dodawany do nazwy typu, aby zbudować nazwę typu zastępczego.

  Na przykład ShimExample jest typem zastępczym typu Example.

• Przedrostek Stub jest dodawany do nazwy typu, aby zbudować nazwę typu namiastki.

  Na przykład StubIExample jest typem wycinka typu IExample.

Argumenty typu i struktury typu zagnieżdżonego

• Argumenty typu ogólnego są kopiowane.

• Struktura typów zagnieżdżonych jest kopiowana dla typów zastępczych.

Konwencje nazewnictwa właściwości delegata zastępczego lub pól delegata namiastki

Podstawowe zasady dla nazewnictwa pól, zaczynają się od pustej nazwy:

• Nazwa metody jest dołączana.

• Jeśli nazwa metody jest jawną implementacją interfejsu, kropki są usuwane.

• Jeśli metoda jest ogólna, dołączane jest Ofn, gdzie n to liczba argumentów metody ogólnej.

Specjalne nazwy metod takie jak właściwości getter lub setter są traktowane jak opisano w poniższej tabeli.

Uwagi

• Gettery i settery indeksatorów traktuje się podobnie do właściwości.Domyślna nazwa indeksatora to Item.

• Nazwy Typ parametru są przekształcane i łączone.

• Typ zwracany jest ignorowany, chyba że istnieje dwuznaczność przeciążenia.Jeśli tak jest, typ zwracany jest dołączany na końcu nazwy

Konwencje nazewnictwa typu parametru

Zasady cykliczne

Następujące zasady są stosowane cyklicznie:

• Ponieważ substytuty używają języka C#, aby wygenerować zestawy pozorne, dowolny znak, który skutkowałby nieprawidłowym tokenem C# jest zmieniany na "_" (podkreślenie).

• Jeśli nazwa wynikowa powoduje konflikt z dowolnym członkiem deklarowanego typu, używany jest schemat numerowania przez dołączenie dwóch cyfr licznika, począwszy od 01.

Zasoby zewnętrzne

Wskazówki

Testowanie dostarczania ciągłego w programie Visual Studio 2012 – Rozdział 2: Testowanie jednostkowe: Testowanie wnętrza

Zobacz też

Koncepcje

Izolowanie testowanego kodu za pomocą struktury Microsoft Fakes