A Java geek

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.

This is the 2nd post in the Going the microservices way focus series. In my previous post, I developed a simple microservices REST application based on Spring Boot in a few lines of code. Now is the time to put this application in the cloud. In the rest of the article, I suppose you already have an account configured for the provider. Pivotal Cloud Foundry is the Cloud offering from Pivotal, based on Cloud Foundry.

This is the 1st post in the Going the microservices way focus series. <div class='paragraph'> <p><a href='https://en.wikipedia.org/wiki/Microservices' target='_blank' rel='noopener'>Microservices</a>, are trending right now, whether you like it or not. There are good reasons for that as it resolves many issues organizations are faced with. It also opens a Pandora box as new issues pop up every now and then…​ But that is a story for another day: in the end, micr