Using the Builder Pattern for Test Fixtures

| Comments

If you read some of my previous blog posts, you may have noticed I’m quite keen on TDD. Writing good tests and writing them first is the only way I know to:

  • prove your code works the way you expect it to
  • ensure a bug you fix now will never find its way back into production
  • properly document your code without the inherent duplication of code comments
  • build a good safety net for refactoring
  • sleep at night

In theory, test methods should be concise, and they should have a given-when-then structure (test setup, actual call to production code, result verification). However, Yogi Berra is right when he says there is no difference between theory and practice in theory, while in practice there is.

So, in this post I’ll try to close that gap between theory an practice a bit, and show why using the builder pattern is a great(*) way to write test fixtures.

Play 1 vs Play 2: Hold Your Horses

| Comments

I work for Cegeka, a company that’s proud of not being the regular type of body-shopping consulting firm. Instead, they put together teams of highly skilled, agile-minded people and sell those to clients as a whole. Needless to say I like it there.

Self-improvement is an important part in their philosophy, and in order to do that Cegeka encourages people to participate in so-called Competence Centers. These are groups of people of the same profession – Spotify would call them guilds – who gather a full day about every two months. Kind of like a playground to learn about technology, if you will.
Since about a year, I’ve been in charge of the Playframework competence center, whose goal it is to investigate how well Play fits the agileTDDDDD way of working, and whether the playframework elevator pitch holds in a more or less real-life project.

Legacy Code, an Epyphany

| Comments

Until recently, I used the term legacy code for bad, ancient code that had been written ten consultants ago, for code that has stopped evolving because it’s too complicated and critical that nobody dares to take responsibility, for code that came from someone else, you get the idea. We’ve all seen that code and we all love to hate that consultant, don’t we.

And then I learned about another definition of legacy code, one that Michael Feathers (@mfeathers) introduced in his book, Working Effectively with Legacy Code:

legacy code is code without tests.

Nice, short and catchy, but until yesterday I didn’t really understand this is indeed a very good definition of legacy code.

Devoxx University Highlights

| Comments

It’s that time of the year again: Devoxx, Antwerp, the largest independent all things JVM conference. Not ‘Java’ anymore, because obviously there are many things going on, and I didn’t attend a single java(-only) flavoured talk in my whole first day.
Some highlights.

Play 2 JUnit Runner

| Comments

I like Play 2. It’s simply the best thing that happened on the JVM since, well, Play 1 :)

One thing bothers me though: testing is still a bit of a PITA (at least in Java). Sure, Play 2 has webdriver support, you don’t have to extend UnitTest and FunctionalTest anymore and you can unit-test templates. But, instead of extending base test classes I have to call a bunch of static utility methods on the play.test.Helpers class.

For example, to write a test that runs inside an application (i.e. has access to its environment), I have to write the following:

In his excellent blog post, Matthieu Guillermin (@mguillermin) shows a solution for this problem (amongs others) by creating an abstract base class that contains the boilerplate code. This works very well, but I prefer composition over inheritance, so I’m using a custom JUnit runner for this.

Then, you can use this runner in an @runWith annotation, and just write your test code without wrapping it in a Runnable, like so:

Until next time!


| Comments

The Belgian Playframework User Group held it’s first coding event last Wednesday: a Coding Dojo.
The ingrediƫnts: 17 nice people, a decent sized room, food and drinks, and Playframework of course.

A Coding Dojo is an event where people gather to code and learn together. The goal of a dojo is exactly that: to code and learn, nothing more. It’s about the journey, not the destination.
Ours was a Randori Kata, a kind of dojo where the whole group works together to build an application in a couple of hours, by pair programming on stage. We changed that format just a wee bit, more on that further down in this post.

PlayBe Dojo: Play 2 & Java

| Comments

Last year at Devoxx, I met Steve Chaloner (@steve_objectify), a Welsh expat in Belgium, and the first guy I met who had been using PlayFramework professionally. Steve and his teammate managed to rewrite a struts 1 app that had been in development for some 4 years and that was ready for the bin. They used PlayFramework and rewrote the app in about a tenth of the original LOCs.
Steve is also the author of Deadbolt, a widely used authorization module for both Play 1 and 2.

For those who don’t know it: Play is a full-stack web framework for the JVM that was built from the ground up by web developers who were tired of the bloated enterprizeness of building web apps in java and decided to do something about it. It’s got strongly typed templates, asset compilation, full statelessness, real hot reloading (it’s stateless, duh), and it’s part of the typesafe stack of which some say it’s a disruptive force, like Spring used to be some time ago.
But my personal favorite is this: change code – hit F5 – do a demo.
In short, it’s the closest thing to PHP you can get as a java/JVM web dev, but without sacrificing your beloved strongly typed objects.

However, being a fanboy is not much fun if you’re the only one, even if you’re two. So somewhere in spring – the season – Steve and I decided to get started with the Belgian Playframework User Group (or #playbe for short). At this moment, the user group has about 30 members.

Now, a couple of months and beer sessions later, we’re very proud to announce PlayBe’s first real event: a Play2 Coding Dojo.
A coding dojo is a live coding event where everybody in the room is invited to participate. The format will be that of a Randori Kata, in which the group collectively builds an application, in our case using Play2 and Java.

What we’ll be building is still a bit of a secret, but I promise it’ll be something you can talk about at home, and maybe even use.
Also, did I mention that there’ll be food and drinks? (Thanks Cegeka for the hosting & sponsoring!).

The Dojo takes place 3 October, 2012 at 7pm, at the Cegeka Offices in Leuven (Belgium).
No PlayFramework experience is required, the only thing you should be familiar with is a keyboard and some Java. We won’t be doing any Scala.
Registration is required, but free.

Hope to see you there!

Extreme Programming Explained, Without Explaining

| Comments

I’ve been reading ‘Extreme Programming Explained – Embrace Change’, by Kent Beck (@kentbeck). If you’ve read it too, you’re probably thinking: “it’s an old book, you should’ve read it years ago”, and I agree. But if you didn’t I can only say: you should.

Even if you’re working on a software development team but are no programmer; XP Explained does not contain any (as in ‘zero’) code samples, and it’s really about how to develop software as a team.

To Test or Not to Test

| Comments

I recently decided to participate in a RAD race, which will be held on 9 and 10 November. A RAD race is a competition in which teams (of two people in this case) build a real-life application in two days, using the language and tools of their choice.


| Comments

println("Hello World!")

First blog post, yay!

Now with that out of the way, go ahead and read the second post. That’ll be a more interesting, I promise.