Z jakiego powodu powinienem kpić?

Question

Jestem również nowy w Mockito i PowerMockito. Dowiedziałem się, że nie mogę przetestować statycznych metod z czystym Mockito, więc potrzebuję użytkownika PowerMockito (prawda?).

Mam bardzo prostą klasę o nazwie Testuj z tym bardzo łatwy sposób

public class Validate { 
     public final static void stateNotNull(
      final Object object, 
      final String message) { 
    if (message == null) { 
     throw new IllegalArgumentException("Exception message is a null object!"); 
    } 
    if (object == null) { 
     throw new IllegalStateException(message); 
    } 
} 

więc muszę sprawdzić, czy:

1) Kiedy ja nazywam to metoda statyczna na pustym wiadomości argumentu IllegalArgumentException nazywa
2) Kiedy zadzwonić, że metoda statyczna na obiekt zerowy argument IllegalStateException nazywa

Z tego, co mam do tej pory pisałem ten test:

import static org.mockito.Matchers.anyString; 
import static org.mockito.Matchers.isNull; 

import org.junit.Before; 
import org.junit.runner.RunWith; 
import org.powermock.api.mockito.PowerMockito; 
import org.powermock.core.classloader.annotations.PrepareForTest; 
import org.powermock.modules.junit4.PowerMockRunner; 
import org.testng.annotations.Test; 

@RunWith(PowerMockRunner.class) 
@PrepareForTest(Validate.class) 
public class ValidateTestCase { 

    @Test(expectedExceptions = { IllegalStateException.class }) 
    public void stateNotNullTest() throws Exception { 
     PowerMockito.mockStatic(Validate.class); 
     Validate mock = PowerMockito.mock(Validate.class); 
     PowerMockito.doThrow(new IllegalStateException()) 
      .when(mock) 
      .stateNotNull(isNull(), anyString()); 
     Validate.stateNotNull(null, null); 
    } 
} 

Więc to mówi, że drwić klasy walidacji i ja sprawdzając, kiedy nazywa się na mock tej metody z pustym argumentem jako przedmiot i dowolny ciąg jako wiadomość, IllegalStateException jest wyrzucane.

Teraz naprawdę nie rozumiem. Dlaczego po prostu nie mogę nazwać tej metody bezpośrednio, rzucając całą magię voodoo na kpiny z tej klasy statycznej? Wydaje mi się, że jeśli nie zadzwonię do Validate.stateNotNull, ten test i tak przepadnie ... Z jakiego powodu powinienem go kpić?

Answer 1

Najpierw zdecyduj, jaki jest Twój cel i co chcesz przetestować. Twój test nie testuje twojej metody klasy Validate, tworzy ona próbę, która zachowuje się jak ta metoda, jako Fortega points out. Określ, co testujesz (testowany obiekt) i czego potrzebujesz, aby wykonać test (współpracowników), a następnie spójrz na współpracowników i zdecyduj, czy są to rzeczy łatwe do utworzenia, czy też potrzebujesz kpić z nich.

Dla czegoś takiego jak ta klasa, która nie ma zależności od czegokolwiek, radziłbym robić bez mocków w całości. Nie ma tu nic, co wymaga szyderczy, badanie może być napisane tak:

import static org.junit.Assert.*; 

public class ValidateTestCase { 

    @Test 
    public void testHappyPath() throws Exception { 
     Validate.stateNotNull("", ""); 
    } 

    @Test 
    public void testNullMessage() throws Exception { 
     try { 
      Validate.stateNotNull(null, null); 
      fail(); 
     } 
     catch (IllegalStateException e) { 
      String expected = "Exception message is a null object!" 
      assertEquals(expected, e.getMessage()); 
     } 
    } 

    @Test(expected=IllegalStateException.class) 
    public void testNullObject() throws Exception { 
     Validate.stateNotNull(null, "test"); 
    } 
} 

i który wskazuje, czy kod robi to, czego chcemy.

Nie ośmieszaj się, chyba że istnieje pewna zależność, której chcesz uniknąć przy wprowadzaniu do testu, ponieważ jest ona zasobem zewnętrznym (takim jak system plików lub baza danych) lub innym złożonym podsystemem. Fałszywe frameworki mogą być bardzo użyteczne, ale zwiększają złożoność, mogą nadmiernie określać zachowanie testowanych rzeczy, powodując, że testy są kruche i mogą sprawić, że testy będą trudne do odczytania. Rób bez nich, jeśli możesz.

Answer 2

Nie powinieneś kpić z klas i metod, które testujesz. Powinieneś kpić tylko z metod potrzebnych do wykonania samego testu.

Na przykład, jeśli do przeprowadzenia testu potrzebne są jakieś obiekty z usługi sieciowej, można naśmiewać się z wywołań usług internetowych, więc nie trzeba wywoływać usługi WWW.