From Spock documentation:
Spock is a testing and specification framework for Java and Groovy applications. What makes it stand out from the crowd is its beautiful and highly expressive specification language.
Spock in an amazing testing framework, which I believe is a better replacement for JUnit library. Using Spock will make your tests not only easier to write, but what is more important, it will make them easier to read and understand their results.
What could be the biggest challenges to switch from JUnit to Spock:
- Spock is using Groovy (not Java) so you need to learn new language.
- Spock is not JUnit so it is not compatible with other software (i.e. IDE, build tools, continuous integration tools).
Fortunatelly, the above statements are false!
It is not always clear what are the requirements for the task to be considered „done”. Each team member might have slightly different understanding of „done” which is build gradually with gaining experience in the team. This can sometimes cause miscommunication and misleading perception of functionality as being production ready. From the team member perspective (especially someone new in the team) it is hard to tell if all the work required for the task, has been completed.
There is a solution for this issue called „Definition of Done” which is well known Agile methodology tool.
I have lately discovered, I wasn’t fully aware how date and time works in Java. In my current project we are using date and time quite heavily, but until recently we were on Java 7 and we have used java.util.Date and Joda-Time library.
Recently things have changed when we’ve started a new project using Java 8 with brand new and shining Date and Time API (JSR 310). Because we are integrating our application with external system which API library was using old java.util.Date, we had to convert data between old java.util.Date and new date and time Java API.
There is a new attribute in HTML5 „contentEditable”. It allows user to edit content of the website elements like „span” or „div”. It might be very useful when you need to make some element editable only in the specific circumstances.
I my TaskRoo project I am using „contentEditable” with AngularJS to make tasks names editable in-place with the double-click.
In this post I will describe how to implement and use AngularJS directive to make HTML element editable in-place. In case you are just looking for solution, you can find complete implementation on plunker:
I know there are already many articles in this topic, but sometimes looking into the codebase, I feel it is still not emphasised enough. This post purpose is to explain why null reference is undesired in clean code. I would like this post to clearly answer why „null” should be avoided if you care about quality of your code.
Last Saturday I took part in the Global Day of Coderetreat 2014 (GDCR2014) in Aspect Capital, London. GDCR is an amazing event organised every year since last 6 years. This year it was organised in 44 countries, 141 cities with about 2500 developers participating.
Long story short – on GDCR there is a simple programming problem to solve: Conway’s Game of Life. The aim is to learn as much as possible and not necessarily solve the problem. To achieve this aim there is 6 pair programming (and TDD) sessions. To make things even more interesting, each session had a different additional constrains and you should pair program with someone else. After each session you remove all you have done so far and start the next one from scratch.
I have never solved the whole problem during the sessions, but I feel, I have learn a lot anyway. The day after the GDCR I have decided I want to finish the task and implement the complete solution for Conway’s Game of Life and so I did.
My solution is available on Github. It is implemented in Scala. There is also small bonus as I have integrated the solution with the GUI implemented in Swing by other GDCR2014 attendee.
At work we are using Groovy language to write the Cucumber acceptance tests. Groovy turns out to be very nice language with flat learning curve for Java developer. There are many interesting features in the language, but I believe some of them have to be used with caution.
As we work more with Groovy and learn more of its features we found there are many ways of doing the same thing. It is useful, because it makes code more expressive, but it can also be an issue when there are multiple developers working on the same code base. This problem most probably exists in every programming language and it can be partially solved by agreeing on the coding conventions. Unfortunately there is no established code convention for Groovy yet as there are for other languages like Java.
In this post I list some features of the Groovy language and try to choose a convention to use. Of course this is not the only correct approach. This is more a try to orginise the conventions and keep it for future reference.
INFO: Unfortunately „–save-config” option is no longer supported in the new versions of gnome-terminal so this script will not work.
I use terminal quite often in my work. I have a specific way how I work with terminal. I usually have about 10 tabs open in different directories so I can quickly switch between them. I felt quite frustrated when I was in the middle of something, but I had to reboot the PC for some reason. It is because it means I would need to set-up my perfect multi-tab terminal from scratch.
Fortunately I found very easy solution for this issue. This article describes easy way to save and restore the terminal session.
Most commonly used set of Java coding conventions comes from Sun Microsystems and it is still available on Oracle website. The document describes many important aspects of formatting, naming conventions etc for Java.
However, for most of the teams it is not enough for two major reasons. First of all, the document has become quite outdated in some cases as it is has been created back in 1999. Things like maximum of 80 characters per line, when most of us use full HD monitors, does not seem right. The other reason is that Sun’s code conventions still leaves a lot of freedom and it is easier to maintain and read the code written in the similar fashion. This is why many teams decide to create additional code conventions on top of the Sun’s document adding more specific things.
In this post I am discussing two of the Java code conventions which are not part of the mentioned official Java code convention, but which are often added on top of it. These two are: keep all variables in the code as „final” and using „this” for every field and method access in class.
With multiple languages working on the same JVM now, it is possible (and easy) to use different languages for your production and test code.
Why not to take this opportunity when it can be easier and faster to write test code. This can be also a good way to learn a new language. You can keep your production code using the language you are the most comfortable with and write your tests in Scala or Groovy.
This post describes how to configure Maven project to use Java as a production code language and Scala with a ScalaTest framework for unit tests.