A Java geek

This is quite an unusual post, as it is the first post of 2016. Moreover, it’s also unusual because it’s my 300th post there! Though it might seem like an ego trip, I feel it’s important to think about the things that lead here. This blog started in April 2008, a little less than 8 years ago. At the time, I was between 2 missions and had much time to spare. I knew I wanted to start a blog, I just didn’t know what I wanted to tell - which basically is the first thing you

Working on a legacy project those last weeks gave me plenty of material to write about tests, Mockito and PowerMock. Last week, I wrote about abusing PowerMock. However, this doesn’t mean that you should never use PowerMock; only that if its usage is commonplace, it’s a code smell. In this article, I’d like to show an example how one can refactor legacy code to a more testable design with the temporary help of PowerMock. Let’s check how we can do that using the following c

Still working on my legacy application, and still trying to improve unit tests. This week, I noticed how much PowerMock was used throughout the tests, to mock either static or private methods. In one specific package, removing it improved tests execution time by one order of magnitude (from around 20 seconds to 2). That’s clearly abuse: I saw three main reasons of using PowerMock. Lack of knowledge of the API There probably must have been good reasons, but some of PowerMock uses could

Last week, I wrote about the ways to initialize your Mockito’s mocks and my personal preferences. I’m still working on my legacy project, and I wanted to go deeper into some Mockito’s feature that are used. For example, Mockito’s developers took a real strong opinionated stance on the design: Mockito can only mock public non-final instance methods. That’s something I completely endorse. To go outside this scope, you’d have to use PowerMock (which I wrote abou

Maintenance projects are not fun compared to greenfield projects, but they sure provide most of the meat for this blog. This week saw me not checking the production code but the tests. What you see in tests reveals much of how the production code itself is written. And it’s a way to change things for the better, with less risks. At first, I only wanted to remove as much PowerMock uses as possible. Then I found out most Mockito spies were not necessary. Then I found out that Mockito mocks

The more I program, the easier it gets. However, the more questions arise regarding programming. This week, my thinking was about Object-Oriented Programming. I’ve been told that OOP is about encapsulating state and behavior is a single isolated unit. In languages I know, state translates into attributes and behavior into methods. public class Cat { private Color color; public void mew() { ... } } That said, unit testing requires the ability to test in isolation: this ha

There’s not one week passing without stumbling upon a post claiming language X is superior to all others, and offers you things you cannot do in other languages, even make your kitchenware shine brightier and sometimes even return lost love. I wouldn’t mind these claims, because some features really open my Java developer mind to the lacking of what I’m using now, but in general, they are just bashing another language - usually Java.

If you haven’t read Uncle Bob latest blog post, you should do now. For impatient readers, it can be summed up with: TL;DR: 'You don’t need frameworks, just write the appropriate code'. It’s not the first time I find myself at odd with Uncle Bob’s writing, which feels awkward in regard to his experience and aura. Another post that drew my attention was about JavaScript.

This is the 3rd post in the Going the microservices way focus series. In the first post of this serie, I created a simple microservice based on a Spring Boot + Data JPA stack to display a list of available products in JSON format. In the second part, I demoed how this app could be uploaded on Pivotal Cloud Foundry. In this post, I’ll demo the required changes to deploy on Heroku.