2017-01-18 42 views
8

Pracuję nad dość małym projektem (pod względem zależności), a gdy tylko uruchomię test jednostkowy, ładowanie JVM zajmie 8 sekund, zanim wykonam właściwy test w 0,2 s.JUnit czas uruchamiania jest powolny

Moja okolica:

  • Java 8
  • Spring Tool Suite 3.8.1.RELEASE
  • JUnit 4
  • Windows 8

Obawiam się, że musi być coś w moim środowisku, które jest przyczyną to trwa tak długo, a Mam nadzieję, że ktoś to wcześniej widział i znalazł źródłem problemu i być może rozwiązaniem? E.g. czy moja zmienna środowiskowa PATH jest naprawdę długa, czy to w ogóle ma znaczenie? Co dokładnie dzieje się po uruchomieniu testu JUnit?

Rzeczywiste testy próbuję uruchomić to:

public class TemplateLocationCalculatorTest { 

    private TemplateLocationCalculator target = new TemplateLocationCalculator(); 

    @Test 
    public void whenGivenRootReturnIndex(){ 
     Assert.assertEquals("index", target.calculate("/")); 
    } 
} 

a klasa celem jest:

public class TemplateLocationCalculator { 

    public String calculate(String string) { 
     return "index"; 
    } 

} 

Mam nadzieję, że zgodzicie się ze mną, kiedy mówię, to nie powinien długo ładować.

+1

@PieterDeBie Zrobiłem. Akapit drugi. Wydajność sprzętu komputerowego nie powinna stanowić problemu. – kinbiko

+0

Przeczytaj za szybko, skasuj mój komentarz :) –

+1

Czy możesz opisać, co dzieje się podczas tych 8 sekund rozruchu? Możesz spróbować podejścia opisanego w [to pytanie] (http://stackoverflow.com/questions/39321345/how-do-i-measure-jvm-startup-time), aby rejestrować różne zdarzenia bootstrap JVM. – apangin

Odpowiedz

2

OP tutaj.

Po suggestion given in the chat użyłem Microsoft Process Monitor i po dużo filtrowania odkryłem, że oprogramowanie AV Avecto DefendPoint został uruchomiony na moim komputerze, a to wydawało się, że był to wąskie gardło. Za każdym razem, gdy rozpoczynam test, będzie on wynosił około 25%, co wydaje mi się wskazywać, że działa z pełną prędkością na pojedynczym wątku na jednym z moich czterech rdzeni. Nie jestem administratorem tego komputera, więc nie mogłem go wyłączyć, aby zweryfikować tę hipotezę, ale generalnie, jeśli inne osoby powinny zobaczyć ten problem, sprawdź, czy może to być oprogramowanie antywirusowe.

-1

Potencjalny reason może być komponentowym skanowaniem i autowirowaniem komponentów podczas rozruchu. Można to ograniczyć, tworząc oddzielny plik config dla testów ograniczających przestrzeń wyszukiwania dla komponentów, jak wyjaśniono w artykule here.

w config, można lazy load beans<beans default-lazy-init="true"> lub jawnie drut fasoli (wyjaśnione bardziej szczegółowo here)

<beans ...> 
    <!-- this bean will be injected into the OrderServiceTest class --> 
    <bean id="target" class="TemplateLocationCalculator" /> 

    <!-- other beans --> 
</beans> 

Następnie w klasie testów, możemy określić nowy plik konfiguracyjny:

@RunWith(SpringJUnit4ClassRunner.class) 
@ContextConfiguration(locations = { "classpath:/path/to/test-config.xml" }) 
public class TemplateLocationCalculatorTest { 

    @Autowired 
    private TemplateLocationCalculator target; 

    @Test 
    public void whenGivenRootReturnIndex(){ 
     Assert.assertEquals("index", target.calculate("/")); 
    } 

} 

@Bean 
public class TemplateLocationCalculator { 

    public String calculate(String string) { 
     return "index"; 
    } 

} 
+1

Wiosna nie jest tutaj używana. To Spring Tool Suite (STS). Czy może miałeś na myśli to, że STS wykonuje autouzupełnianie pod maską, nawet jeśli uruchamiany jest prosty i prosty test JUnit? – Roland

+0

STS to wtyczka, która wstępnie instaluje komponenty Spring IDE - pod maską wciąż jest wiosna. Mimo że jest to tylko test JUnit, aplikacja musi być zbudowana i uruchomiona, aby nadal działało automatyczne okablowanie. Chodzi o uproszczenie tego procesu. –

+0

ok ... Miałem na myśli, że Wiosna nie jest tutaj bezpośrednio używana. Jeśli STS wykonuje okablowanie pod maską, co spowalnia proces, a twoja odpowiedź to rozwiązuje, wszystko jest w porządku ;-) – Roland