preparing to run junit 5 with eclipse and maven

Main menu:

Topics

Recent Posts

Feeds

RSS Feed RSS - Posts

August 2017
M T W T F S S
« Jul    
 123456
78910111213
14151617181920
21222324252627
28293031  

Past Posts

Java/Java EE

JDBC

Other

preparing to run junit 5 with eclipse and maven

August 13th, 2017 by Jeanne Boyarsky

I’ve been playing with JUnit 5 for a while. Since I’m going to be speaking about it at JavaOne, I decided to write all my tests using JUnit 5 between now and then. Plus we are getting close to JUnit 5’s official release; it’s pretty stable now.

Since it is more than just playing, I wanted my IDE to support it. And my Maven POM needed to know about both JUnit 4 and 5. It wasn’t hard.

Update Eclipse

I also decided to update my Eclipse so I could run JUnit 5 tests in the workspace.  I had to let Eclipse update 3 other plugins to be compatible with the latest version. It was easy to do though and I didn’t need to re-install my custom plugins. In September (or so), Eclipse will release with JUnit 5 support in it.

Update Maven POM

Then I updated my pom to use the dependencies in the JUnit 5 Maven sample. I also added failsafe support and junit-jupiter-params dependency (for parameterized tests which I use a lot)

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>GROUP_ID_GOES_HERE</groupId>
  <artifactId>ARTIFACT_ID_GOES_HERE</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <properties>
    <java.version>1.8</java.version>
    <surefire.version>2.19.1</surefire.version>
    <junit.version>4.12</junit.version>
    <junit.jupiter.version>5.0.0-RC2</junit.jupiter.version>
    <junit.vintage.version>${junit.version}.0-RC2</junit.vintage.version>
    <junit.platform.version>1.0.0-RC2</junit.platform.version>
  </properties>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-failsafe-plugin</artifactId>
        <version>${surefire.version}</version>
        <executions>
          <execution>
            <goals>
              <goal>integration-test</goal>
              <goal>verify</goal>
            </goals>
          </execution>
        </executions>
        <dependencies>
          <dependency>
            <groupId>org.junit.platform</groupId>
            <artifactId>junit-platform-surefire-provider</artifactId>
            <version>${junit.platform.version}</version>
          </dependency>
        </dependencies>
      </plugin>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.0</version>
        <configuration>
          <source>${java.version}</source>
          <target>${java.version}</target>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>${surefire.version}</version>
        <configuration>
          <includes>
            <include>**/Test*.java</include>
            <include>**/*Test.java</include>
            <include>**/*Tests.java</include>
            <include>**/*TestCase.java</include>
          </includes>
          <properties>
            <!-- <includeTags>fast</includeTags> -->
            <excludeTags>slow</excludeTags>
          </properties>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.junit.platform</groupId>
            <artifactId>junit-platform-surefire-provider</artifactId>
            <version>${junit.platform.version}</version>
          </dependency>
        </dependencies>
      </plugin>
    </plugins>
  </build>
  <dependencies>
     <dependency>
       <groupId>org.junit.jupiter</groupId>
       <artifactId>junit-jupiter-api</artifactId>
       <version>${junit.jupiter.version}</version>
       <scope>test</scope>
     </dependency>
     <dependency>
       <groupId>org.junit.jupiter</groupId>
       <artifactId>junit-jupiter-params</artifactId>
       <version>${junit.jupiter.version}</version>
       <scope>test</scope>
     </dependency>
     <dependency>
       <groupId>junit</groupId>
       <artifactId>junit</artifactId>
       <version>${junit.version}</version>
       <scope>test</scope>
     </dependency>
     <dependency>
       <groupId>org.junit.platform</groupId>
       <artifactId>junit-platform-launcher</artifactId>
       <version>${junit.platform.version}</version>
       <scope>test</scope>
     </dependency>
     <dependency>
       <groupId>org.junit.jupiter</groupId>
       <artifactId>junit-jupiter-engine</artifactId>
       <version>${junit.jupiter.version}</version>
       <!-- docs don't have this as test scope; trying anyway to see what happens -->
       <scope>test</scope>
     </dependency>
     <dependency>
       <groupId>org.junit.vintage</groupId>
       <artifactId>junit-vintage-engine</artifactId>
       <version>${junit.vintage.version}</version>
       <!-- docs don't have this as test scope; trying anyway to see what happens -->
       <scope>test</scope>
     </dependency>
     <!-- other dependencies my project needs like selenium go here -->
  </dependencies>
</project>

Problems I encountered (with solutions)

  1. Maven doesn’t run failsafe tests – Originally I didn’t have failsafe version 2.19.1 because I had copied the pom from the junit sample. And the JUnit sample didn’t have any integration tests so no reason to include failsafe.
  2. Eclipse doesn’t recognize migrated JUnit 5 tests – If you’ve ever run JUnit 4 tests against that project/test, Eclipse has a stored configure with the test runner set to JUnit 4. You can go to “run configurations” and either delete the existing configuration or change the runner to JUnit 5 for that configuration. I choose the later:

Remember that with this configuration, you are merely prepared to have JUnit 5 tests in your project. Since JUnit 5 is (mostly) backward compatible, the tests still work as is.

 

“why did you decide not to be a developer”

August 5th, 2017 by Jeanne Boyarsky

Last week, I got asked “why did you decide not to be a developer” by a junior developer while we were pair programming. My first reaction was “I am a developer”. My second was confusion as we were writing Selenium/JUnit code at the time of the question. She was typing and I was the navigator. (In this particular pairing session, she was the driver for 95% of the time as I’ve worked with Selenium extensively and she had never used it before. The only times I drove were for a few “Java idioms” where I wanted to show how it was done.)

After I got past my first two reactions, I gave a far better response. Another teammate IM’d me to say it was a good explanation and I replied that it would make an excellent blog post. So here’s that blog post.

There’s different types of developers

I’m currently on a Dev Ops type team. We do tools and consulting to teams creating business applications. (usually web apps but not always.) I consider myself a developer. I write code. I deliver software. Sometimes that software is a standalone tool we wrote. Sometimes it is automation for an open source tool. Sometimes is it is customization. Sometimes it is automation of a task. Sometimes it is a requirement that the open source software doesn’t meet. But I write code regularly at work. I also read code regularly to troubleshoot open source code.

Frequency of coding on my previous team

On my previous team, I was a business/web application developer. Towards the end, I had advanced to the point where I was the tech lead and SQE (software quality engineer). And this was a decent sized team so it took up time. I spent a lot of team mentoring others, doing analysis, in meetings, etc. I didn’t code every day on that team, so typing code can’t be the measure of a developer role. Interestingly, the code I write on my current team is often harder/more technical than the code I wrote on my previous team!

First time idea of being on the dev ops team full time

A teammate floated the idea of me being on the tooling team full time a good number of years ago. At that point, I wasn’t even able to think about it. I needed the experience of being a tech lead/architect/whatever of a larger team before I was willing to “specialize”. So I understand the question. But it’s not a matter of not being a developer. It’s a matter of being a different type of developer.

My title/department

My title is still developer and I’m still in a development department. That hasn’t changed. So my company thinks of me as a developer too. It’s just that our customers are now developers too while they used to be the business.

Programmer vs developer

This wasn’t in my answer, but I want to include it here. There’s a difference between being a programmer and a developer. We aren’t just boxes that take in detailed requirements and spit out code. That’s true on any team.

Finally

Finally, the good news is that she asked the originally question because she was impressed with my coding skills.

how easy should be it reach an author?

July 22nd, 2017 by Jeanne Boyarsky

I was reading Deep Work:Rules for Focused Success in a Distracted World. On page 243, the author writes:

Most nonfiction authors are easy to reach. They include an e-mail address on their author websites along with an open invitation to send them any request or suggestion that comes to mind. Many even encourage this feedback as a necessary commitment to the elusive but much-touted importance of “community building” among their readers. But here’s the thing: I don’t buy it.

Scott and I are non-fiction authors of three cert books. We don’t encourage email. We do encourage communication. All three of our books encourage readers to contact us using the forums at CodeRanch.com. This works well for us because there are others who have the possibility to answer and it doesn’t come with a quick reply assumption. (Although we often do reply within a day or two if nobody else has first).

We do like hearing from readers. We like hearing about their success on the exam. We like hearing when they find an errata. (see why posting errata matters). We like hearing what they are looking for clarification.

I wonder if this comes from our domain. Computer programmers don’t write a book expecting to make loads of money. And we aren’t required to publish for our jobs. The author of this book is a professor. So I wonder if he thinks of his book differently? Or if it is that Scott and I were active on the forums before writing a book so wish to remain accessible?