Uruchamianie testów ogórka z kategoriami Junit za pośrednictwem Maven

Question

Mam projekt maven z wieloma modułami i jednym wspólnym modułem nadrzędnym. W tym projekcie są testy jednostkowe uruchamiane z Junit razem z surefire, a także testy integracji BDD Cucumber. Chciałbym uruchomić dwa osobne zadania, jeden do uruchomienia wszystkich testów jednostkowych i jeden do uruchomienia testów BDD/Integration. W tym celu, mam odnotowany moje klasy biegacz BDD z kategorii adnotacji JUnit tak:

@RunWith(Cucumber.class) 
@CucumberOptions(
       tags = { "@ATagToBeRun", "~@ATagNotToBeRun","~@ToBeImplemented" }, 
       dryRun = false, strict = true, 
       features = "src/test/resources/cucumber/testing", 
       glue = { "com.some.company.test", 
         "com.some.company.another.test"}) 
@Category(value = IntegrationTest.class) 
public class FlowExecutionPojoTest { 
} 

stworzyłam profil Maven w dominującej pom który wykorzystuje funkcję maven-surefire-plugin, który jest przeznaczony do filtrowania bazy testów na grupy. Oto moja konfiguracja Maven:

 <dependencies> 
     <dependency> 
      <groupId>info.cukes</groupId> 
      <artifactId>cucumber-java</artifactId> 
      <version>1.2.4</version> 
      <scope>test</scope> 
     </dependency> 

     <dependency> 
      <groupId>info.cukes</groupId> 
      <artifactId>cucumber-junit</artifactId> 
      <version>1.2.4</version> 
      <scope>test</scope> 
     </dependency> 

     <dependency> 
      <groupId>info.cukes</groupId> 
      <artifactId>cucumber-spring</artifactId> 
      <version>1.2.4</version> 
      <scope>test</scope> 
     </dependency> 
     <dependency> 
      <groupId>info.cukes</groupId> 
      <artifactId>cucumber-jvm-deps</artifactId> 
      <version>1.0.5</version> 
      <scope>test</scope> 
     </dependency> 
    </dependencies> 

    <profile> 
     <id>testJewels</id> 
     <activation> 
      <activeByDefault>true</activeByDefault> 
     </activation> 
     <modules> 
      <module>../my-module</module> 
     </modules> 
     <build> 
      <plugins> 
       <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-surefire-plugin</artifactId> 
        <version>2.19.1</version> 
        <configuration> 
         <groups>com.some.company.IntegrationTest</groups> 
        </configuration> 
       </plugin> 
      </plugins> 
     </build> 
    </profile> 

Co spodziewałem się, że gdy uruchamiam mvn test -PtestJewels klas adnotacją z kategorii zawartych w znaczniku <groups> powinny być wykonywane. W rzeczywistości żadna z adnotowanych klas nie została wykonana.

Interesujący jest fakt, że kiedy użyłem maven-surefire-plugin wersji 2.18, zadziałało to, ale z wersji 2.18.1 i tak się nie stało. Według documentation w dolnej części strony, nastąpiła zmiana w wersji 2.18.1 dotyczące kategorii dziedziczone, ale w moim przypadku są one będąc w

Answer 1

odkryłem, że istnieje rzeczywiście pull request w repozytorium cucumber-jvm ustalenia ten konkretny problem. Problem jest spowodowany faktem, że gdy Junit filtruje klasy runner testu na podstawie adnotacji @Category, sprawdza również wszystkie klasy potomne. W przypadku testu ogórek, który uruchamia pliki .feature, wszystkie klasy reprezentujące pliki .feature są również sprawdzane (koniczyna konwertuje każdy plik .feature w instancji klasy FeatureRunner). Ponieważ adnotacja nie istnieje w klasie FeatureRunner, testy są filtrowane i nie są uruchamiane. (Przed wersją 2.18.1 klasa maven-surefire-plugin nie sprawdzała klas podrzędnych pod kątem adnotacji i dlatego nie stanowiło to problemu.)

Obejście, które działa w przypadku określonej konfiguracji, którą opisałem powyżej, gdzie wszystkie testy BDD są wykonywane specyficzny moduł był na modyfikację konfiguracji <groups> w module dziecka, tak jak poniżej:

<build> 
    <plugins> 
     <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-surefire-plugin</artifactId> 
      <configuration> 
       <groups combine.self="override"></groups> 
      </configuration> 
     </plugin> 
    </plugins> 
</build> 

to oczywiście nie działać w innej konfiguracji, a zatem raczej niefortunne, że zespół ogórek ma jeszcze scalić PR o których wspomniałem powyżej: