Spring testing on steriods

Posted by Lars Vonk at 8:49 pm Development, Java, Testing 1 Response »
Feb 092011

Recently I was involved in another Spring powered Java project and noticed a lot of test specific xml configuration floating around. Typically this is done because (for instance) datasources and such that are not available via JNDI outside a container. Problem that I have with the specific xml configuration is that it is maintenance intensive and well it is more xml… :-) Luckily you almost never have to create the specific XML files to be able to test your application context outside a container.
Continue reading »

Share
Tagged with: , ,

Towards an immutable domain model – believe the type (part 4)

Posted by Erik Rozendaal at 6:30 pm Development, Scala 1 Response »
Feb 072011

We’re already on the fourth part of this series. The previous parts consist of:

  1. a not totally trivial example implemented using JPA and Scala
  2. an event sourced implementation using explicit state changes
  3. a straightforward translation of the mutable event sourced implementation into an immutable implementation

In this part we’ll explore how we can improve on the original design now that the invoice is immutable.
Continue reading »

Share
Tagged with: , , , , , ,

Towards an immutable domain model – immutability achieved (part 3)

Posted by Erik Rozendaal at 2:05 pm Development, Scala 2 Responses »
Feb 052011

In part 1 we looked at a stereotypical implementation of an Invoice domain class. In part 2 we introduced event sourcing to extract the durability and reporting concerns from the behavioral requirements and to move closer to making the Invoice immutable. In this part we’ll explore the first implementation of an immutable Invoice.
Continue reading »

Share
Tagged with: , , , , , ,

Towards an immutable domain model – immutable change (part 2)

Posted by Erik Rozendaal at 8:59 pm Development, Scala 4 Responses »
Feb 022011

In the first part of this series an Invoice domain object was defined as a starting point for discussing immutable domain objects. JPA and Scala were used for the example implementation. In this part we’ll look at this example from a different perspective to move closer to an immutable domain model.
Continue reading »

Share
Tagged with: , , , , , , ,

Towards an immutable domain model – introduction (part 1)

Posted by Erik Rozendaal at 8:07 pm Development, Scala 3 Responses »
Feb 012011

This is the first part of a (short) series of blogs on implementing a rich domain model using only immutable domain objects. This first part introduces a (simple) example domain model and provides a JPA implementation using Scala. This exampe will serve as a baseline that should be familiar to most developers who have experience with an ORM. The other parts of this series will redesign the example to use only immutable objects and will explore some of the benefits and drawbacks of doing so.
Continue reading »

Share
Tagged with: , , , , , ,

Option[Scala]… a better null?

Posted by Erik Rozendaal at 9:16 pm Development, Java, Scala 2 Responses »
Jan 232011

Yesterday I watched Graham Tackley’s talk (slides) on moving from Java to Scala at guardian.co.uk. The presentation is well worth watching if you’re considering adding Scala to your project.

One of the highlights for me was to see how easy it is to integrate Scala with the regular Java development and deployment process and how the team’s coding style evolved and improved as their understanding of Scala increased.

Another interesting point was that after a year of using Scala the team’s favorite feature was the Option type.

Option

Anyone new to Scala will quickly encounter the Option type. An Option[T] represents a value that may be present (containing Some value of type T) or is not there (None). Java has a similar facility built right into the language: nulls. So what makes Options so great compared to nulls?
Continue reading »

Share
Tagged with: , , , ,

Crap-o-meter

Posted by Lars Vonk at 9:53 pm Development, Java 1 Response »
Jan 192011

There has been a lot of talk about craftsmanship these days. I didn’t care much about the discussion whether we are craftsman or not. To me all that matters is what Uncle Bob says about it in one of his latest blog posts: We are tired of writing Crap.
But was is crap? And how do you know you are making a mess of things? So for your benefit I created the following Crap List. It’s opensource and free of use. It is mainly targeted on Java, but a lot also applies to other ecosystems. Please add as much crap to it as you like.
So here we go…
Continue reading »

Share
Tagged with: , ,

Fixing date in test using JUnit MethodRule

Posted by Lars Vonk at 3:39 pm Development, Java, TDD No Responses »
Jan 142011

One of the principles of a good unit test is that they are repeatable. This is especially important if the tests involve dates. Typically this is programmed in the setUp and tearDown of the unit tests. This might lead to duplication if multiple tests depend on such a fixed date. Of course we can abstract this to an Abstract base class, but in the end we all know that reuse via inheritance is a bad idea. JUnit @Rule can be a solution for this.
Continue reading »

Share
Tagged with: , , , ,

Bowling Game Kata in Ruby

Posted by Lars Vonk at 3:24 pm Ruby, TDD 3 Responses »
Dec 302010

As a good pragmatic programmer you should learn at least one new language per year. For me this year’s (2011) language will be Ruby (I know I am a bit late…). A Kata is an excellent and fun way to learn a new progamming language as well as your (new) IDE or text editor. As Kata I chose the Bowling Game Kata from Uncle Bob. Read on if you want to see how my Bowling Game looks like in Ruby.
Continue reading »

Share

Organizing test code in Java

Posted by Sander Nieuwenhuizen at 1:42 pm TDD 1 Response »
Nov 192010

A short while back I started to work with Ruby on Rails. Incredible fun and inspiring. One of the (many) things I like is the distinction Rails creates of the different levels of test scopes. It has separate folders to store unit, functional, integration and performance tests.

Now in Java – and using the Maven default folder layout – you get one folder for storing your production code (src/main/java) and one for your test code (src/test/java). That got me to thinking to apply Rails’ way to structure your Java test suite. After a while it can be tricky to organize to test code, so I wanted to give it a shot with Java.
Continue reading »

Share
Tagged with: , ,
Older Entries Newer Entries
© 2012 Zilverblog Suffusion theme by Sayontan Sinha