I had a need to stub a method the other day that had a var arg method. I failed in stubbing it using Mockito. It disturb me a lot. But after mulling on the problem a while, I searched and found a simple solution.
Mockito has a
anyVararg() method that you should use when you try to stub a method that takes a var arg as argument.
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.
I had a discussion about an automation task that I have implemented the other day.
The task is about automating the deployment of a web application on top of a JBoss. The application is old and we are not allowed to do any improvements at the moment. The instruction is, deploy it as it is at the moment. You will be allowed to do improvements later when you are able to deploy the application smothly.
I saw a wonderful reference on Twitter the other day. It quoted something called Gall’s law.
I looked it up and noticed that this seems to be a valid reference made by Dr. John Gall in a book from 1975.
A Continuous Integration, CI, server builds a system every time a change has been detected in the version control system. This is a very common practice and something good. We are able to catch many silly mistakes early. The question is, what should the CI server build? Which artifact should the build produce?
This blog post is the same as the example I presented at GeeCON TDD in Poznan, Poland, January 2015. It is a step-by-step example that I hope you will be able to follow and implement yourself.
But before I begin with the implementation, let me reason about why you should care about BDD.
Behaviour Driven Development, BDD, is a way to try to bridge the gap between developers, who can read code, and people who are less fluent in reading code. Cucumber is not a tool only for acceptance testing. It is a communication tool where you can express examples in plain text that anyone can read. These examples can also be executed. They are the outcome from discussions between stakeholders, developers and testers.
Given this, the technical part of BDD that I will show you is the less important part. The most important part is the conversations that occurs and defines the application that should be implemented.
You are recruiting a new software developer to your team. How can you decide that this candidate is a good candidate?
The only good way I know is to work together. And do it for some time, preferably a few weeks.
I came across this tweet the other day:
“Novice engineers have not yet grokked this: the number of modes or options in your system is the *exponent* in how hard it is to maintain.” by @zooko.
This is very true. The more options a system has, the harder it is to understand, maintain and use. This is one of the reasons why I usually always try to hard code things like parameters to scripts in my first iteration.
Hard coding is something that some of my colleagues sometimes have a hard time to accept. It happens that the argument is “I don’t like hardcoded things”. I can understand that point of view and I extract parameters when I have got one use case working with a hard coded solution. But I don’t do it before I have something working.