Spock Framework executes test methods (features) in a single class (specification) in the declaration order. There is nothing wrong in this default behavior - we should write tests with their isolation in mind. However, in some cases, we would like to randomize test methods execution. Today we are going to learn how to do it.
I’ve never enjoyed working with regular expressions in Java. It was always very error-prone. You had to remember to escape backslashes, and a very simple match elements check required writing at least 5 lines of code. Booooring. However, Groovy solved most of these issues, and today we are going to take a closer look at features like pattern operator, find operator or exact match operator. We will focus on learning the new syntax, as well as measuring and comparing its performance. Let’s begin!
One of the most interesting Groovy features is its ability to configure advanced compiler options using DSL script. It becomes handy when you want to apply some global modifications to all Groovy classes. (For instance, you want to add
@CompileStatic annotation to all classes, without applying changes to the source code). In most cases, you want to add something to the existing source code, e.g., classes imports or useful annotations, but what if we want to remove one annotation or another?
GraalVM 1.0.0-RC11 was released yesterday, and I thought it would be an excellent excuse to play around with it a while. I decided to create a simple Groovy script that uses Grape dependency management system to load an external library and create a standalone native image from it. I thought it wouldn’t be possible, but luckily - I was wrong.
Ignoring some of the unit tests when given conditions are not satisfied is a handy feature of a JUnit framework. I guess you have used many times constructions like
Assume.assumeNotNull(expr) in your test code. Today I would like to show you one pretty interesting corner case when the usage of
Assume.assumeNotNull(expr) throws NPE in the unit test written in Groovy.
Groovy has many useful functions built-in, and one of them is
Iterable.combinations() that takes aggregated collections and finds all combinations of items. However, if we take a look its source code, we will find out that it was implemented using very imperative approach (nested for-loops + some if-statement). In this blog post I will show you how to implement the same function using Groovy and tail-recursion algorithm. Enjoy!
Most of the object-oriented programmers prefer constructing algorithms using imperative style over using recursion. This is pretty obvious in the JVM ecosystem, where imperative iteration is much more efficient than recursive function call chain. However, what if I tell you that in Groovy you can take advantage of clean tail-recursive functions without sacrificing performance? Interested? Let’s deep dive into it.
GraalVM became one of the most popular topics in the JVM ecosystem. It promises the highest possible speed of running JVM-based programs (when compiled to native images), hand in hand with the smaller memory footprint. It sounds interesting enough to give it a try. And today we are going to play around a little bit with running simple Groovy program after compiling to a standalone native image.