Jaka jest różnica między udawaniem, wyśmiewaniem i stubowaniem?

Stub - obiekt, który dostarcza predefiniowanych odpowiedzi na wywołania metod.

Mock - Obiekt, na którym ustawiasz oczekiwania.

Fake - obiekt o ograniczonych możliwościach (na potrzeby testowania), np. fałszywy serwis internetowy.

Test Double jest ogólnym terminem dla stubów, szyderstw i podróbek. Ale nieformalnie, często słyszycie, jak ludzie nazywają ich kpinami.

Jestem zaskoczony, że to pytanie istnieje od tak dawna i nikt jeszcze nie udzielił odpowiedzi na podstawie "Sztuka testowania jednostkowego "Roya Osherove'a .

W "3.1 Wprowadzenie stubów" definiuje stub jako:

Stub jest kontrolowalnym zamiennikiem istniejącej zależności (lub współpracownika) w systemie. Za pomocą Stuba możesz przetestować swój kod bez radzenie sobie z zależnością bezpośrednio.

I określa różnicę między stubs and mocks as:

Najważniejsze, aby pamiętać o mocks kontra stubs jest to, że mocks są tak samo jak stubs, ale twierdzisz przeciwko obiektowi mock, podczas gdy nie twierdzisz przeciwko stubowi.

Fake to tylko nazwa używana zarówno dla stubów, jak i wyśmiewców. Na przykład, gdy nie dbasz o rozróżnienie między stubami i wyśmiewcami.

Sposób, w jaki Osherove rozróżnia stuby i mocki, oznacza, że każda klasa używana jako podróbka do testowania może być zarówno stub lub mock. To, co jest dla konkretnego testu, zależy całkowicie od tego, jak piszesz testy w teście.

• kiedy twój test sprawdza wartości w testowanej klasie, a właściwie gdziekolwiek poza fake, fake był używany jako punkt zwrotny. Po prostu dostarczył wartości dla testowanej klasy do użycia, albo bezpośrednio przez wartości zwracane przez wywołania na niej lub pośrednio przez wywołanie efektów ubocznych (w pewnym stanie) w wyniku wywołania na niej.
• kiedy twój test sprawdza wartości fałszywego, był używany jako makieta.

Przykład testu, w którym Klasa FakeX jest używana jako stub:

const pleaseReturn5 = 5;
var fake = new FakeX(pleaseReturn5);
var cut = new ClassUnderTest(fake);

cut.SquareIt;

Assert.AreEqual(25, cut.SomeProperty);

Instancja fake jest używana jako stub, ponieważ Assert w ogóle nie używa fake.

Przykład testu, w którym Klasa testowa X jest używana jako makieta:

const pleaseReturn5 = 5;
var fake = new FakeX(pleaseReturn5);
var cut = new ClassUnderTest(fake);

cut.SquareIt;

Assert.AreEqual(25, fake.SomeProperty);

W tym przypadku Assert sprawdza wartość na fake, czyniąc fałszywą makietę.

Zgadzam się z Osherove ' S, że

Z czystej perspektywy konserwacji, w moich testach używanie Mock ' ów stwarza więcej kłopotów niż nie używanie ich. To było moje doświadczenie, ale zawsze uczę się czegoś nowego.

Twierdzenie o fake jest czymś, czego naprawdę chcesz uniknąć, ponieważ sprawia, że twoje testy są wysoce zależne od implementacji klasy, która nie jest testowana w ogóle. Co oznacza, że testy dla klasy ActualClassUnderTest mogą zacząć się łamać, ponieważ implementacja dla ClassUsedAsMock uległa zmianie. I to wysyła do mnie nieprzyjemny zapach. Testy na ActualClassUnderTest powinny zostać przerwane tylko wtedy, gdy ActualClassUnderTest zostanie zmieniona.

Zdaję sobie sprawę, że pisanie twierdzeń przeciwko fake ' owi jest powszechną praktyką, zwłaszcza gdy jesteś makietycznym subskrybentem TDD. Myślę, że jestem mocno z Martinem Fowlerem w obozie klasycystycznym (Patrz Martin Fowler ' s "Mocks are not Stubs") i jak Osherove unikaj testowania interakcji (które można zrobić tylko poprzez twierdzenia przeciwko fałszywemu) w jak największym stopniu.

Dla Zabawy czytanie, Dlaczego należy unikać kpin, jak zdefiniowano tutaj, google dla "Fowler mockist klasycysta". Znajdziesz mnóstwo opinii.

Jak wspomniano w najczęściej głosowanej odpowiedzi, Martin Fowler omawia te rozróżnienia w Wyśmiewcy nie są Stubami, a w szczególności podtytuł różnica między Wyśmiewcami a Stubami, więc przeczytaj ten artykuł.

Zamiast skupiać się na Jak te rzeczy są różne, myślę, że bardziej pouczające jest skupianie się na dlaczego są to różne pojęcia. Każdy istnieje w innym celu.

Podróbki

A fake jest implementacja, która zachowuje się "naturalnie", ale nie jest "realna". Są to niejasne pojęcia i tak różni ludzie mają różne rozumienie tego, co sprawia, że rzeczy są fałszywe.

Przykładem fałszywki jest baza danych w pamięci (np. używając SQLite ze sklepem :memory:). Nigdy nie użyłbyś tego do produkcji (ponieważ dane nie są przechowywane), ale jest to doskonale odpowiednie jako baza danych do użycia w środowisku testowym. Jest również znacznie bardziej lekki niż" prawdziwa " baza danych.

Jako inny Amazon S3), ale w teście można po prostu zapisać obiekty do plików na dysku; wtedy implementacja "save to disk" byłaby fałszywa. (Lub możesz nawet sfałszować operację "Zapisz na Dysku", używając zamiast tego systemu plików w pamięci.)

Jako trzeci przykład, wyobraź sobie obiekt, który zapewnia interfejs API pamięci podręcznej; obiekt, który implementuje poprawny interfejs, ale który po prostu nie wykonuje buforowania, ale zawsze zwraca brak pamięci podręcznej to byłaby podróbka.

Celem fałszywki jest Nie wpływanie na zachowanie testowanego systemu , ale raczej uproszczenie implementacji testu (poprzez usunięcie zbędnych lub ciężkich zależności).

Stuby

A stub jest implementacją zachowującą się "nienaturalnie". Jest wstępnie skonfigurowany (zwykle przez ustawienie testowe) do odpowiedzi na określone wejścia z określonymi wyjściami.

Celem stub jest aby Twój system był testowany w określonym stanie. na przykład, jeśli piszesz test dla kodu, który współdziała z API REST, możesz stub out API REST z API, które zawsze zwraca odpowiedź canned lub które odpowiada na żądanie API z określonym błędem. W ten sposób można napisać testy, które sprawiają, że twierdzenia o tym, jak system reaguje na te stany; na przykład, testowanie odpowiedzi otrzymanej przez użytkowników, jeśli API zwróci błąd 404.

Stub jest Zwykle zaimplementowane, aby reagować tylko na dokładne interakcje, na które kazałeś mu reagować. Ale kluczową cechą, która sprawia, że coś stub jest jego cel : stub polega na skonfigurowaniu twojego przypadku testowego.

Kpiny

A mock jest podobny do Stuba, ale z dodaną weryfikacją . celem makiety jest stwierdzenie, w jaki sposób testowany system oddziaływał z zależnością.

Na przykład, jeśli piszesz test w przypadku systemu, który przesyła pliki do witryny internetowej, możesz zbudować makietę , która akceptuje plik i której możesz użyć do stwierdzenia, że przesłany plik był poprawny. Lub, w mniejszej skali, często używa się makiety obiektu do sprawdzenia, czy testowany system wywołuje określone metody wyśmiewanego obiektu.

Mocks są związane z testowaniem interakcji , które jest specyficzną metodologią testowania. Ludzie, którzy wolą testować Stan systemu niż system interakcje będą używać szyderstw oszczędnie, jeśli w ogóle.

Test podwaja

Podróbki, stuby i kpiny należą do kategorii podwajania testów . Podwójny test to dowolny obiekt lub system, którego używasz w teście zamiast czegoś innego. Większość zautomatyzowanych testów oprogramowania polega na użyciu testowych sobowtórów tego lub innego rodzaju. Niektóre inne rodzaje podwójnych testów obejmują wartości atrapowe, spies i I / O blackholes.

Aby zilustrować użycie stubów i mocks, chciałbym również dołączyć przykład oparty na Roya Osherove ' a "The Art of Unit Testing ".

Wyobraź sobie, że mamy aplikację LogAnalyzer, która ma jedyną funkcjonalność drukowania dzienników. Nie tylko musi rozmawiać z serwisem internetowym, ale jeśli serwis internetowy wyświetli błąd, LogAnalyzer musi zalogować błąd do innej zewnętrznej zależności, wysyłając go pocztą e-mail do Administratora serwisu internetowego.

Oto logika, którą Lubię testować wewnątrz LogAnalyzer:

if(fileName.Length<8)
{
 try
  {
    service.LogError("Filename too short:" + fileName);
  }
 catch (Exception e)
  {
    email.SendEmail("a","subject",e.Message);
  }
}

Jak sprawdzić, czy LogAnalyzer poprawnie wywołuje usługę e-mail, gdy serwis internetowy wyrzuca wyjątek? Oto pytania, z którymi mamy do czynienia:

• Jak zastąpić serwis internetowy?

• W jaki sposób możemy symulować wyjątek z usługi internetowej, abyśmy mogli przetestować połączenie do usługi e-mail?

• Skąd będziemy wiedzieć, że usługa e-mail została poprawnie wywołana lub na wszyscy?

Możemy poradzić sobie z dwoma pierwszymi pytaniami przez używając Stuba dla serwisu internetowego. Aby rozwiązać trzeci problem, możemy użyć makiety obiektu dla usługi e-mail .

Podróbka jest ogólnym terminem, który może być używany do opisania stub lub mock.In nasz test, będziemy mieli dwa podróbki. Jednym z nich będzie makieta usługi e-mail, której użyjemy do sprawdzenia, czy prawidłowe parametry zostały wysłane do usługi e-mail. Drugim będzie stub, którego użyjemy do symuluje wyjątek wyrzucony z usługi internetowej. Jest to stub, ponieważ nie będziemy używać serwisu internetowego fake, aby zweryfikować wynik testu, tylko aby upewnić się, że test działa poprawnie. Usługa e-mail jest makietą, ponieważ będziemy twierdzić, że została poprawnie wywołana.

[TestFixture]
public class LogAnalyzer2Tests
{
[Test]
 public void Analyze_WebServiceThrows_SendsEmail()
 {
   StubService stubService = new StubService();
   stubService.ToThrow= new Exception("fake exception");
   MockEmailService mockEmail = new MockEmailService();

   LogAnalyzer2 log = new LogAnalyzer2();
   log.Service = stubService
   log.Email=mockEmail;
   string tooShortFileName="abc.ext";
   log.Analyze(tooShortFileName);

   Assert.AreEqual("a",mockEmail.To); //MOCKING USED
   Assert.AreEqual("fake exception",mockEmail.Body); //MOCKING USED
   Assert.AreEqual("subject",mockEmail.Subject);
 }
}

Rzecz, którą na nim twierdzisz, nazywa się mock obiekt, A Wszystko inne, które pomogło w uruchomieniu testu, to stub .

To kwestia ekspresji testów. Ustawiłem oczekiwania na makiecie, jeśli chcę, aby test opisywał związek między dwoma obiektami. Zwracam wartości, jeśli konfiguruję obiekt pomocniczy, aby doprowadzić mnie do interesującego zachowania w teście.

Jeśli znasz Arrange-Act-Assert, to jednym ze sposobów wyjaśnienia różnicy między stubem a mockiem, który może być dla ciebie przydatny, jest to, że stuby należą do sekcji arrange, ponieważ służą do porządkowania stanu wejściowego, a mocki należą do sekcji assert, ponieważ służą do sprawdzania wyników.

Manekiny nic nie robią. Służą one tylko do wypełniania list parametrów, dzięki czemu nie pojawią się błędy undefined lub null. Istnieją również w celu spełnienia sprawdzania typu w ściśle wpisywane języki, dzięki czemu można je kompilować i uruchamiać.

Stub, podróbki i kpiny mają różne znaczenia w różnych źródłach. Proponuję przedstawić warunki wewnętrzne zespołu i uzgodnić ich znaczenie.

Myślę, że ważne jest, aby rozróżnić dwa podejścia: - Walidacja zachowania (implikuje substytucję zachowania) - Walidacja stanu końcowego (implikuje emulację zachowania)

Rozważ wysyłanie wiadomości e-mail w przypadku błędu. Podczas sprawdzania zachowania - sprawdzasz, czy metoda Send z IEmailSender została wykonana raz. Oraz musisz emulować return result tej metody, zwracając Id wysłanej wiadomości. Więc mówisz: "spodziewam się, że Send zostanie wywołany. I po prostu zwrócę dummy (lub losowe) Id dla każdego połączenia " . To sprawdzanie zachowania: emailSender.Expect(es=>es.Send(anyThing)).Return((subject,body) => "dummyId")

Podczas walidacji stanu musisz utworzyć TestEmailSender, który implementuje IEmailSender. I zaimplementować metodę Send - zapisując dane wejściowe do jakiejś struktury danych, która będzie użyta do przyszłej weryfikacji stanu jak tablica niektórych obiektów SentEmails, a następnie testuje sprawdź, czy SentEmails zawiera oczekiwany e-mail. To jest Walidacja stanu: Assert.AreEqual(1, emailSender.SentEmails.Count)

Z moich odczytów zrozumiałem, że sprawdzanie zachowania zwykle nazywane wyśmiewa . I Walidacja stanu zwykle nazywane Stubami lub podróbkami .

Unit testing - jest podejściem do testowania, w którym jednostka (Klasa, metoda) jest pod kontrolą.

Test double - nie jest głównym obiektem (ze świata OOP). Jest to realizacja, która jest tworzona tymczasowo w celu przetestowania, sprawdzenia lub w trakcie rozwoju. Test podwaja typy:

• fake object jest rzeczywistą implementacją interfejsu (protokołu) lub rozszerzenia, które wykorzystuje dziedziczenie lub inne podejścia, które można wykorzystać do stworzenia - is zależność. Zwykle jest tworzony przez programista jako najprostsze rozwiązanie do zastąpienia pewnej zależności

• stub object jest gołym obiektem(0, nil i metody bez logiki) z dodatkowym stanem, który jest predefiniowany(przez programistę) do zdefiniowania zwracanych wartości. Zazwyczaj jest tworzony przez framework

• mock object jest bardzo podobny do stub object, ale dodatkowy stan jest zmieniany podczas wykonywania programu, aby sprawdzić, czy coś się stało (metoda została called).

• spy object jest realnym obiektem z "częściowym wyśmiewaniem". Oznacza to, że pracujesz z nie-podwójnym obiektem, z wyjątkiem wyśmiewanego zachowania

• dummy object jest obiektem koniecznym do uruchomienia testu, ale żadna zmienna lub Metoda tego obiektu nie zostanie wywołana.

Stub vs mock

Martin Fowler powiedział

Jest różnica w tym, że stub używa weryfikacji stanu, podczas gdy mock używa zachowania weryfikacja.

[Mockito mock vs spy]

Stub i fake są obiektami, które mogą zmieniać swoją odpowiedź na podstawie parametrów wejściowych. główną różnicą między nimi jest to, że podróbka jest bliższa rzeczywistemu wdrożeniu niż stub. Stuby zawierają zasadniczo zakodowane odpowiedzi na oczekiwane żądanie. Zobaczmy przykład:

public class MyUnitTest {

 @Test
 public void testConcatenate() {
  StubDependency stubDependency = new StubDependency();
  int result = stubDependency.toNumber("one", "two");
  assertEquals("onetwo", result);
 }
}

public class StubDependency() {
 public int toNumber(string param) {
  if (param == “one”) {
   return 1;
  }
  if (param == “two”) {
   return 2;
  }
 }
}

Amock jest krokiem w górę od podróbek i stubów. Mocki zapewniają taką samą funkcjonalność jak stuby, ale są bardziej złożone. Mogą mieć określone dla nich zasady, które dyktują w jakiej kolejności należy wywoływać metody na ich API. Większość mocks może śledzić, ile razy metoda została wywołana i może reagować na podstawie tych informacji. Szydercy zazwyczaj znają kontekst każdego połączenia i mogą reagować inaczej w różnych sytuacjach. Z tego powodu szydercy wymagają pewnej wiedzy na temat klasy, którą wyśmiewają. na ogół nie można śledzić, ile razy metoda została wywołana lub w jakiej kolejności została wywołana Sekwencja metod. Makieta wygląda tak:

public class MockADependency {

 private int ShouldCallTwice;
 private boolean ShouldCallAtEnd;
 private boolean ShouldCallFirst;

 public int StringToInteger(String s) {
  if (s == "abc") {
   return 1;
  }
  if (s == "xyz") {
   return 2;
  }
  return 0;
 }

 public void ShouldCallFirst() {
  if ((ShouldCallTwice > 0) || ShouldCallAtEnd)
   throw new AssertionException("ShouldCallFirst not first thod called");
  ShouldCallFirst = true;
 }

 public int ShouldCallTwice(string s) {
  if (!ShouldCallFirst)
   throw new AssertionException("ShouldCallTwice called before ShouldCallFirst");
  if (ShouldCallAtEnd)
   throw new AssertionException("ShouldCallTwice called after ShouldCallAtEnd");
  if (ShouldCallTwice >= 2)
   throw new AssertionException("ShouldCallTwice called more than twice");
  ShouldCallTwice++;
  return StringToInteger(s);
 }

 public void ShouldCallAtEnd() {
  if (!ShouldCallFirst)
   throw new AssertionException("ShouldCallAtEnd called before ShouldCallFirst");
  if (ShouldCallTwice != 2) throw new AssertionException("ShouldCallTwice not called twice");
  ShouldCallAtEnd = true;
 }

}

Wszystkie z nich są nazywane testami podwójnymi i używane do wprowadzania zależności, których potrzebuje twój przypadek testowy.

Stub: Ma już predefiniowane zachowanie, aby ustawić swoje oczekiwania na przykład funkcja stub zwraca tylko przypadek pomyślności odpowiedzi API

Makieta to mądrzejszy stub. Sprawdzasz, czy twój test przechodzi przez to. więc możesz zrobić amock, że powrót sukcesu lub porażki sukces w zależności od stanu może zostać zmieniony w Twoim przypadek testowy.