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/thinkcode.se/build.gradle:37) 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/thinkcode.se/build.gradle:37)
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.(more...)
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
I have. More than once and been very frustrated. These are tools I like. Not getting good messages upsets me.(more...)
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.(more...)
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.(more...)
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.(more...)
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.(more...)
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.(more...)
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.(more...)