2016-10-25 13 views
9

Stworzyłem wiele testów sprężynowych, (z spring-boot1.4.0).testowanie wiosennego rozruchu - czy test wielokrotny może współdzielić jeden kontekst?

FirstActionTest.java:

@RunWith(SpringRunner.class) 
@WebMvcTest(FirstAction.class) 
@TestPropertySource("classpath:test-application.properties") 
public class FirstActionTest { 
    @Autowired 
    private MockMvc mvc; 

    // ... 
} 

SecondActionTest.java:

@RunWith(SpringRunner.class) 
@WebMvcTest(SecondAction.class) 
@TestPropertySource("classpath:test-application.properties") 
public class SecondActionTest { 
    @Autowired 
    private MockMvc mvc; 

    // ... 
} 

Po uruchomieniu testu poprzez:

testu mvn

Wygląda na to, że utworzono kontekst testu sprężynowego dla każdej klasy testowej, co nie jest konieczne, jak sądzę.

Pytanie brzmi:

  • Czy to możliwe, aby udostępnić jeden sprężynowy kontekst testową między wieloma klasy testowej, a jeśli tak, to w jaki sposób?
+0

tak, jest to możliwe. http://stackoverflow.com/a/8502023/410677 – kuhajeyan

+0

@kuhajeyan Link do konfiguracji opartej na xml, nawet w spring2.5 możemy to zrobić całkiem łatwo. Ale w przypadku wiosennego rozruchu zwykle nie ma pliku konfiguracyjnego dla kontekstu, nie wiem, jak to zaadaptować do wiosennego rozruchu. –

+0

@EricWang szukasz tego samego? czy byłeś w stanie znaleźć na nie odpowiedź? – Ahmed

Odpowiedz

5

Dzięki zastosowaniu dwóch różnych klas z @WebMvcTest (tj @WebMvcTest(FirstAction.class) i @WebMvcTest(SecondAction.class)) Jesteś szczególności wskazując, że chcesz różnych kontekstów aplikacji. W tym przypadku nie można udostępnić pojedynczego kontekstu, ponieważ każdy kontekst zawiera inny zestaw komponentów. Jeśli jesteś kontrolerem, fasola zachowuje się dość dobrze, wtedy kontekst powinien być względnie szybki i naprawdę nie powinno być problemu.

Jeśli naprawdę chcesz mieć kontekst, który można buforować i udostępniać we wszystkich testach internetowych, musisz upewnić się, że zawiera on dokładnie te same definicje komponentów bean. Dwie opcje, które przychodzą na myśl:

1) Użyj @WebMvcTest bez określonego kontrolera.

FirstActionTest:

@RunWith(SpringRunner.class) 
@WebMvcTest 
@TestPropertySource("classpath:test-application.properties") 
public class FirstActionTest { 
    @Autowired 
    private MockMvc mvc; 

    // ... 
} 

SecondActionTest:

@RunWith(SpringRunner.class) 
@WebMvcTest 
@TestPropertySource("classpath:test-application.properties") 
public class SecondActionTest { 
    @Autowired 
    private MockMvc mvc; 

    // ... 
} 

2) Nie używaj @WebMvcTest wcale tak masz kontekstu aplikacji, który zawiera wszystkie fasoli (nie tylko, dotyczy internetowych)

Pierwsza ActionTest:

@RunWith(SpringRunner.class) 
@SpringBootTest 
@TestPropertySource("classpath:test-application.properties") 
public class FirstActionTest { 
    @Autowired 
    private MockMvc mvc; // use MockMvcBuilders.webAppContextSetup to create mvc 

    // ... 
} 

SecondActionTest:

@RunWith(SpringRunner.class) 
@SpringBootTest 
@TestPropertySource("classpath:test-application.properties") 
public class SecondActionTest { 
    @Autowired 
    private MockMvc mvc; // use MockMvcBuilders.webAppContextSetup to create mvc 

    // ... 
} 

Należy pamiętać, że w pamięci podręcznej kontekst może uczynić prowadzenie wielu testów szybciej, ale jeśli wielokrotnie uruchomiony jeden test w czasie rozwoju, ty "ponoszą koszty wytworzenia dużej ilości ziaren, które natychmiast zostają odrzucone.

+1

Do autowiring MockMvc można również dodać adnotację '@ AutoConfigureMockMvc' podczas wykonywania' @ SpringBootTest' – Ahmed

+0

Dzięki za jasne wyjaśnienie, myślę, że "opcja 1)" byłby fajny dla projektów, które mają wiele wiosennych testów mvc. Byłoby pomocne, gdyby te informacje mogły znaleźć się w dokumentach dotyczących wiosennego rozruchu. –

+0

Kiedy używam '@ WebMvcTest' bezpośrednio bez klasy kontrolera podanej dla testu i uruchamiam' test mvn', nie udało się znaleźć zależności, które zostały automatycznie wywołane, a błąd wygląda następująco: 'Przyczyna: org.springframework.beans.factory. UnsatisfiedDependencyException: Błąd podczas tworzenia komponentu bean o nazwie "sportsFieldAction": Niezadowolona zależność wyrażona za pomocą pola "dao": Nie znaleziono kwalifikującej się fasoli typu [com.sportslight.dao.SportsFieldDao] dla zależności [com.sportslight.dao.SportsFieldDao] ", dlatego wydaje się, że kontekst nie znalazł fasoli, nie wiem dlaczego. –

Powiązane problemy