Tuesday, 1 December 2020

SpringBoot repackaging and maven.failsafe.plugin

There is an interesting issue with the interaction between springboot and the maven failsafe plugin.  Normally both of these plugins have no problems but often in springboot we want to repackage into an executable springboot jar.  The normal way to do this is,

        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>${spring.boot.version}</version>
            <executions>
                <execution>
                    <goals>
                       <goal>repackage</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>


However, this causes problems with the failsafe plugin not finding some of the classes it needs for testing.  There are two possible solutions to this issue, either is fine.

Change the spring repackage to include a classifier


      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <configuration>
          <classifier>exec</classifier>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>repackage</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

Manually include the classes in the failsafe plugin


      <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-failsafe-plugin</artifactId>
          <version>2.22.2</version>
          <configuration>
              <additionalClasspathElements>
                  <additionalClasspathElement>${basedir}/target/classes</additionalClasspathElement>
              </additionalClasspathElements>
          </configuration>
          <executions>
              <execution>
                  <id>integration</id>
                  <phase>integration-test</phase>
                  <goals>
                      <goal>integration-test</goal>
                  </goals>
              </execution>
          </executions>
      </plugin>

Cucumber set up for SpringBoot and JUnit 4 or JUnit 5

Cucumber has worked well with pure JUnit 4 projects for quite some time.  The transition to JUnit 5 does change things slightly but the change isn't particularly bad once things are set up. Here are the versions that I've been using for these tests

SpringBoot: 2.4.0
Cucumber: 6.9.0
maven.surefire.plugin: 2.22.2
maven.failsafe.plugin: 2.22.2

JUnit4

pom.xml

The Pom must include the dependencies as follows (versions have been dropped off here)

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-java</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-junit</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-spring</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>

CucumberIT.java

The CucumberIT class is the bootstrap part of the cucumber testing.  We see here the JUnit4 @RunWith.  The feature files are set here to be in the src/tests/resources/features directory.

import io.cucumber.junit.CucumberOptions;
import io.cucumber.junit.Cucumber;
import org.junit.runner.RunWith;

@RunWith(Cucumber.class)
@CucumberOptions(
    features = "src/test/resources/features",
    tags = "",
    plugin = {"pretty", "json:target/cucumber.json"})
public class CucumberIT {}

CucumberSpringContext.java

This is where the spring wiring gets done to make sure that SpringBoot starts.  I've also included @AutoConfigureMockMvc for making rest calls to the spring boot service from the Step definitions but you don't have to include that.  If you have additional spring configuration you can add @Beans into this class but you need to include the @ContextConfiguration spring annotation too.  In previous versions of cucumber before the @CucumberContextConfiguration annotation was available you needed to have a blank cucumber @Before in this class to make sure it was found.

In fact once this is set up it stays the same for JUnit 4 and 5 because it is primarily a spring configuration not a Cucumber one!

import io.cucumber.spring.CucumberContextConfiguration;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;

@CucumberContextConfiguration
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
public class CucumberContextTestConfiguration {}

Feature file and properties

As previously mentioned the feature files now go into the src/test/resources/features directory which is referenced in the CucumberIT.  No other properties are necessary for JUnit4


Running with JUnit5

The transition to JUnit5 can happen in two stages.  Firstly just running with JUnit5 can be backwards compatible with all the current JUnit4 annotations and setup with minimal changes.  Here are the changes that need to be made.

Also check out details about the surefire and failsafe plugins which have had problems with JUnit5 before versions 2.22.0 because they can't find JUnit5 tests.

pom.xml

The only differences here are that the junit:junit:4 dependency comes out and the JUnit5 dependencies come in.  Make sure you include the junit-vintage-engine which is what provides the backwards compatibility for JUnit4 annotations, imports etc


        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-java</artifactId>
            <version>${cucumber.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-junit</artifactId>
            <version>${cucumber.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-spring</artifactId>
            <version>${cucumber.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.junit.vintage</groupId>
            <artifactId>junit-vintage-engine</artifactId>
            <scope>test</scope>
        </dependency>

CucumberIT.java

This stays the same

Feature file and properties

The feature file stays as was because it is still directly referenced by the CucumberIT class.  However, there is now a warning from Cucumber about the cucumber report.  This can be removed by including a new file cucumber.properties in src/test/resources

cucumber.properties

cucumber.publish.enabled=false
cucumber.publish.quiet=true


Full JUnit5

Now for fully transitioning to run cucumber with JUnit 5.  The test discovery mechanism has changed between JUnit4 and JUnit5 which is the reason for much of the following change. There are no longer any @CucumberOptions so these have to be specified in property files instead.

pom.xml

The junit-vantage-engine dependency has gone and the cucumber-java dependency is replaced with a JUnit5 specific one.  Again the specific versions have been ignored here



        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-java</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-junit-platform-engine</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-spring</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <scope>test</scope>
        </dependency>

CucumberIT.java

The JUnit4 annotations are no longer available so we use the new JUnit5 annotation - note the different import path.  

import io.cucumber.junit.platform.engine.Cucumber;

@Cucumber
public class CucumberIT {}

Feature file and properties

By default the feature files need to be in the same package as the CucumberIT class (the class annotated with @Cucumber) so they are moved.  The cucumber.properties file that we introduced earlier now has to be renamed to junit-platform.properties (but it stays in src/test/resources).  Also, because the @CucumberOptions no longer exists we can include the plugin options here too

junit-platform.properties

cucumber.plugin=pretty,json:target/cucumber.json
cucumber.publish.enabled=false
cucumber.publish.quiet=true

Thursday, 11 June 2020

New Windows Terminal

Windows have recently introduced a new tabbed terminal which allows different terminal types to be used within one main window.  This is a huge improvement over having a number of cmd prompts open or even using Console2.

To make the new terminal even better you can also add in other terminals that you want to open as a tab.  Using this functionality with Git Bash is a good way to go.

Add Git Bash

Open the terminal and click the down arrow in the menu bar.  Choose Settings.  Notepad should open and the settings can now just be edited there.  To add Git Bash as an option edit the settings and simply add the Git Bash settings as below

  {
      // Make changes here to the gitbash profile.
      "guid": "{00000000-0000-0000-0000-000000000001}",
      "name": "Git Bash",
      "commandline": "C:\\Program Files\\Git\\bin\\bash.exe -i -l",
      "hidden": false,
      "icon" : "C:\\Program Files\\Git\\mingw64\\share\\git\\git-for-windows.ico",
      "startingDirectory" : "%USERPROFILE%"
  },

If you want to make Git Bash the default then you just change the defaultValue setting towards the top of the file

    "defaultProfile": "{00000000-0000-0000-0000-000000000001}",

Save the changes and Terminal will automatically update and Git Bash will be available.