Generowanie kodu, kompilacji i konwencje nazewnictwa towarami podrobionymi Microsoft

Artykuł
03/12/2013

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

Dowiesz się:

Code generation and compilation

Fakes Naming Conventions

Generowanie i kompilacja kodu

Konfigurowanie generowania kodu namiastek

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żna dodać nieograniczoną liczbę elementów Clear, Add, Remove do elementu StubGeneration, aby zbudować listę wybranych typów.

Na przykład ten plik .fakes generuje procedur wejścia dla typów w obszarze nazw systemu i System.IO, z wyłączeniem dowolnego typu zawierającego "Obsługiwać" w systemie:

<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;wopasuje 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 konfiguracyjnego .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>

Podpisywanie silną nazwą

Framework Fakes automatycznie podpisze wygenerowany zestaw pozorny, gdy zestaw zastępczy jest podpisany silną nazwą.Framework Fakes zawsze użyje tego samego klucza, chyba że użytkownik określił inny klucz do podpisania zestawu.Inny klucz można określić w pliku .fakes.

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

Typy wewnętrzne

Generator kodu pozornego wygeneruje typy zastępcze i typy namiastki dla typów widocznych dla wygenerowanego zestawu pozornego.Aby uczynić typy wewnętrzne widocznymi, można dodać atrybut InternalsVisibleTo do zestawu zastępczego, który uczyni widocznym wygenerowany zestaw pozorny.

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

Framework Fakes automatycznie podpisze wygenerowany zestaw pozorny, gdy zestaw zastępczy jest podpisany silną nazwą.W takim przypadku atrybut InternalsVisibleToAttribute musi odnosić się do nazwy zestawu, jak również klucza publicznego.Fakes Framework zawsze używa tego samego klucza do podpisania zestawu, więc użyj tego kawałka jako punkt startowy do dodania atrybutu InternalsVisibleTo do projektu.

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

Optymalizacja czasu kompilacji

Kompilacja zestawów pozornych może znacznie zwiększyć czas kompilacji.Generując zestawy pozorne dla zestawów .NET i zestawów innych firm w osobnym scentralizowanym projekcie można 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.

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.
Dodaj odwołanie do wszystkich zestawów System i innych firm, dla których potrzebujesz substytutów.
Dodaj plik .fakes dla każdego z zestawów i skompiluj projekt.
Z poziomu projektu testu dodaj odwołanie do zestawu, przejdź do folderu Fakes.Prebuild\FakesAssemblies i znajdź odpowiedni zestaw.

Unikanie konfliktu nazw zestawów

W środowisku zespołowej kompilacji 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 utworzyć 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żna zmienić lub usunąć tę wersję przez edycję atrybutu Version elementu Assembly 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 przyrostek .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 namiastki typu IExample.

Argumenty typów i struktury typów zagnieżdżonych

Argumenty typów ogólnych 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, Ofn jest dołączane, 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.

Jeśli metoda to...	Przykład	Dołączana nazwa metody
Konstruktor	.ctor	Constructor
Statyczny konstruktor	.cctor	StaticConstructor
Akcesora za pomocą metody nazwa składa się z dwóch części oddzielonych "_" (na przykład realizuje)	kind_name (taka sama wielkość liter, ale nie wymuszona przez ECMA)	NameKind, gdzie obie części nazwy zostały napisane z wielkiej litery i zamienione
	Getter właściwości Prop	PropGet
	Setter właściwości Prop	PropSet
	Akcesor dodający zdarzenie	Add
	Akcesor usuwający zdarzenie	Remove
Operator składający się z dwóch części.	op_name	NameOp
Na przykład: operator +	op_Add	AddOp
Dla operatora konwersji, dołączany jest typ zwracany.	T op_Implicit	ImplicitOpT

Uwagi

Gettery i settery indeksatorów traktuje się podobnie do właściwości.Domyślna nazwa indeksatora to Item.
Nazwy typów 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

Podając	Dołączany ciąg to...
TypT	T Obszar nazw, struktury zagnieżdżone i tiki ogólne, są opuszczane.
Parametr outout T	TOut
Parametr refref T	TRef
Typ tablicowyT[]	TArray
Typ tablicy wielowymiarowejT[ , , ]	T3
Typ wskaźnikaT*	TPtr
Typ ogólnyT<R1, …>	TOfR1
Argument typu ogólnego!i typu C<TType>	Ti
argument metody ogólnej!!i metody M<MMethod>	Mi
Typ zagnieżdżonyN.T	N jest dołączany, następnie T

Zasady cykliczne

Następujące zasady są stosowane cyklicznie:

Ponieważ podrobionych używa języka C# do generowania zestawów podrobionych, dowolny znak, który produkują nieprawidłowy token C# jest wyjściowym do "_" (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

Badania na nieprzerwane z Visual Studio 2012-rozdział 2: Testowanie jednostek: testowanie wewnątrz

Zobacz też

Koncepcje

Izolowanie testowanego kodu za pomocą struktury Microsoft Fakes

Udostępnij za pośrednictwem