Gradle: setTestClassesDir(File) method has been deprecated

Filed under: Gradle, — Tags: Deprecation — Thomas Sundberg — 2017-08-14

When upgrading from Gradle 3 to Gradle 4, I got a deprecation warning in my build. The message looked like this:

Gradle now uses separate output directories for each JVM language, but this build assumes a single directory for all classes from a source set. This behaviour has been deprecated and is scheduled to be removed in Gradle 5.0
        at build_6ku42cnecj8o3fcbd4eugmgr$_run_closure3.doCall(/Users/tsu/projects/tsu/
The setTestClassesDir(File) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use the setTestClassesDirs(FileCollection) method instead.
        at build_6ku42cnecj8o3fcbd4eugmgr$_run_closure3.doCall(/Users/tsu/projects/tsu/

My question was "What? How do I upgrade my build to get rid of the warning?". I searched but neither Google nor Gradle had a migration plan ready for me.


Hamcrest, JUnit, Mockito, IntelliJ IDEA, Gradle, and java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch

Filed under: Gradle, JUnit, Mockito, TDD, — Tags: Hamcrest, IntelliJ IDEA — Thomas Sundberg — 2016-04-18

Ever included Mockito in your project and lost the nice feedback from Hamcrest? And only when running your unit tests from IntelliJ IDEA? Instead of a message describing what you should fix, you see java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch

I have. More than once and been very frustrated. These are tools I like. Not getting good messages upsets me.


Gradle and Cucumber-JVM

Filed under: Cucumber, Gradle, Programming, — Tags: Cucumber-JVM, JUnit, Java — Thomas Sundberg — 2015-12-26

Gradle is a great build tool. Cucumber-JVM is a great tool for executing Gherkin. They don't really work well together. At least not out of the box. Gradle defaults to hide the output on stdout and stderr. This is very unfortunate since this means that the code snippets Cucumber-JVM suggests when there is a missing step are hidden.

Let me show you an example on how to setup a Gradle project so it can execute Cucumber-JVM and give you the snippets you want as starting points for your steps.


Continuous deployment - a case study

Filed under: Automation, Continuous deployment, Gradle, — Tags: Gradle Plugin, Jenkins, Puppet, artifactory, continuous delivery, continuous deployment, rpm — Thomas Sundberg — 2015-12-23

Continuous deployment is considered, among some enlightened, to be the holy grail in many organisations where software is developed.

What is continuous deployment then? My interpretation is that every change is deployed into production. That is, every change that passes the quality gates the team has created.

A relaxed version is continuous delivery. Continuous delivery means that every change that passes the quality gates ends up as a release candidate. A release candidate that is possible to deploy into to production. The deployment will, however, be done later. If ever.

I will describe how I implemented continuous deployment for one product and continuous delivery for three others for a client.


Separating acceptance tests

Filed under: Gradle, Java, Programming, Test automation, Tools, — Tags: Acceptance Test Driven Development, Acceptance testing, Acceptance tests, Automation, Separating tests — Thomas Sundberg — 2015-04-29

It is very convenient to run the unit tests separated from other, slower, tests. There are different ways to do this. One way is to have a separate module for the acceptance tests.

Separating the modules is acceptable in some cases. It is not acceptable in others. There is a simple way to separate the source code for the acceptance tests while keeping the it in the same project if you use Gradle. Separate the tests with different source sets.

Separation on source sets means that you will keep all the acceptance tests in another directory structure than the unit tests. If you use the usual separation of production code and test code, then all you want to do is to add a new source set that contains the acceptance tests.


A Gradle plugin written in Java

Filed under: Gradle, Java, Programming, — Tags: Automation, Gradle plugin — Thomas Sundberg — 2015-03-22

Gradle is a build automation system. You write your build script in Groovy. This is different compared to other build system such as Ant or Maven. They both use xml. Using Groovy instead of xml gives you a lot of benefits. You have an entire programming language at your disposal. This mean that you can easily customize the build behaviour.

If you, however, want to be able to do the same thing in many projects, it may be a good idea to write a plugin that you can refer to from other projects. I will show you, step by step, how to implement a Hello World Gradle plugin.


Cucumber-JVM Hello world with Gradle

Filed under: Cucumber, Gradle, Maven, — Tags: Automation, Cucumber-jvm — Thomas Sundberg — 2014-08-24

Cucumber is very easy to run from Maven. How do you run it from Gradle?

The answer to this question is: It is as easy as to run it from Maven. Depending on your background, perhaps even easier. The reason for this is because we run Cucumber from a JUnit runner. That is as a unit test with a specific runner. Maven or Gradle really doesn't have anything to do with this. It all boils down to the need for a Gradle project that can build a Java project. A Java project that has a unit test.


Comparing Maven and Gradle

Filed under: Gradle, Maven, — Tags: 4GL, Java — Thomas Sundberg — 2014-07-02

I have been using Maven for a long time. I used to use Ant and it took me a while to get used to Maven and accept the Maven way. Reading a blog post from Neal Ford Why Everyone (Eventually) Hates (or Leaves) Maven got me thinking. He talks about the popularity of 4GL, Fourth Generation Languages, during the 1990s and why they never really took off. The idea was great, but they were not able to solve the entire problem good enough. They solved perhaps 80% easily and the rest was harder and the last part was even harder to solve. The customers want this last part as well and that is the reason why we use general purpose programming languages today.

I used Paradox to build a system for a customer a long time ago. I was able to solve most of their problems.

One thing though, there was an error situation and the customer demanded a correct error message. My problem was that it was a system error that came from the runtime environment that I couldn't control. My solution? To patch the binary that I delivered my application with. I replaced the error message with another message. I was lucky, the message I needed was one character shorter so the binary format was never changed. I am not sure that it was legal, I never asked Borland about it. But the error message became correct and the customer was happy and so was I.





Clean code
Continuous delivery
Continuous deployment
Continuous integration
Executable specification
Load testing
New developers
Pair programming
Public speaking
Software craftsmanship
Software development
Technical debt
Test automation
eXtreme Programming


Thomas Sundberg
Adrian Bolboaca



rss RSS