Monthly Archives: March 2011

Slick java library and 64 bit

Note: This post offers a Windows JAR/DLL package. I have delivered a newer version, also for Linux/Mac OS X. Get them from here

A long while ago I played around with Slick. A game library for Java. It offers easy 2d graphics drawing with the speed of OpenGL (by using LJWGL). It has much more features than that as well. 

When I tried it I was running Win XP 32 bit. However, recently I was trying my code again, this time on Windows 7 64 bit, and I encountered the following error:

lwjgl.dll: Can’t load IA 32-bit .dll on a AMD 64-bit platform

I could not find a decent solution easily, but I fixed it by doing this:
Get the latest source of Slick
Download the latest LJWGL version
– Use the latest LJWGL JAR and DLL files and put them into the latest source code of Slick
– Run “ant dist” of Slick

Use the newly generated JAR of Slick and the new DLL files of LJWGL together, and you’re all set for 32 AND 64 bit!

If you just want to download everything (DLL and JAR’s), I’ve made a little archive for Windows users. It is unofficial though, no support given!. Grab it from here.

The ‘unit’ in unit testing; and kinds of unit tests.

Recently I had the oppertunity to explain some students about what unit testing was. I started off with the question of “What does unit testing mean?”. They gave different types of answers. One of them talked about the smallest piece of code. And even though he is ‘right’. I asked him to apply this knowledge to his current code where he said “But I don’t want to test my get/set methods, that is useless!”. And so, our definition of ‘unit testing’ became unclear again.

So what is a unit test? According to this article on wikipedia “A unit is the smallest testable part of an application”. But what does that mean? What is the ‘smallest testable part’? Do you need to test get/set methods? Do you need to test assigning values? Yes and no.

Even though the smallest testable part is related to lines of code, I believe it also is related to behavior. I think a better description for unit testing would be to test the smallest piece of behavior of an application. Most of the time you probably will be testing very little pieces of code with it. As long as there is some behavior (context) you want to test.

So do get/set methods fall into this category? Depends… Get/Set methods in themselves are, without context, useless. Returning a value or setting a value is not much worth of testing. However, if you test a method that calls a get/set method and does something with it, that is another story. When code is executed within a certain context, it is perfectly valid to unit test it. An example: getTotalPrice that just returns a value “price” is not worth to be testing. A getTotalPrice that does some calculation is a good candidate to test!

With software development, it is the expected behavior of the software that matters. I compare this with designing interfaces (seperating what and how), where you’re busy thinking what you would expect from a certain object when using it. The behavior of the software; how it presents itself and how the user can interact with it (the how), is different from how the software realizes this behavior (the what). When thinking in terms of behavior when writing code, we force ourselves to think of what the software should be doing, and not *how* it should be coded to do that. Test Driven Development is a way of forcing you to write code that has a good design. It clearly a functional (behavior) point of view.

With that said, a unit test should aim to test the smallest possible piece of behavior. When a total price is shown. There are a few steps taken before it is shown on the screen. One of the important behaviors is that the totalprice is calculated somewhere. Testing the calculation of the totalprice is a unit test. This is a State based test. (Does the class give expected output X when using input Y?)

The totalPrice is calculated from certain input. The output is shown on the screen.
A controller class is putting input and output together, making sure the totalPrice is being calculated and pushed to the view. Making sure that the controller uses its collaborators to do that is also a unit test. This is called a collaboration test. (Does my class call the collaborators that I expect, with the parameters I expect?, yes you do that by Mocking)

Even though with these two tests, you still miss an important type of test. You still need to test if your interfaces behave as they say they should. Should you test interfaces of external (3rd party) API’s? Probably not. Unless you have a reason to distrust your supplier of the API. Testing interfaces are called Contract Tests and look a lot like State based tests. These tests are making sure your expectations about the interfaces are validated! If you don’t do that you will get defects, even though you test states and behaviors.

Last but not least. It is useful to test broader pieces of behavior. For example, if you use Spring to bootstrap your webapp. You probably need to make sure everything is autowired correctly. That is an integration test. There are multiple types of integration tests. An often used integration test is to connect to a database, put data in, fire up some methods and test their behavior. All of them are integration tests. Hence, even testing whole pages (end-to-end tests) using Selenium, those are also integration tests, although at a much higher level.

In time I will blog more about the type of unit tests.

My experience with (un)certainty about estimates in relation to technical debt

Not too long ago, Martin Fowler pointed out a nice blog post by Jay Fields. Jay Fields refers to a nice talk he had about accidental complexity and essential complexity and how this has impact on your estimates. He found that not all developers consider the accidental complexity and therefor have lower estimates.

I found this a very interesting thought. It got me thinking how I estimate and how far I’m off. I found that, especially with larger solutions, I’m most of the time under estimating. Even with more complex things, and adding some ‘unforseen complexity percentage’. I’m still under estimating most of the time. However, I’ve also had better experience on other projects. Especially the latest project I’m working on the estimates of fixes and rework are not as much off. How is this possible?

I find myself labeling this phenomenom as “lack of overview”. If you read the definition of Accidental Complexity, it is described as “…accidental complexity is caused by the approach chosen to solve the problem.”. I believe this ‘approach chosen to solve the problem’ is the design of the code. This is different comparing to Essential Complexity, which I belief is much like Cyclomatic Complexity.

I made mistakes with my estimates, even when I knew the code well. Often it was due a dependency that ‘got in the way’, or worse, the lack of dependencies. All functionality was in one class! Adding similar behaviour required me to duplicate code. I consider this a bad practice, so I had to extract code from the other class. I was untangling the code. Whenever I had to untangle that code (ie, seperate concerns), I had a hard time doing so: Because untangling a tangled (tightly coupled) piece of code forced me to untangle other pieces of code as well. I had to stop somewhere. Like someone once said to me: The devil is in the details. (this is one of the reasons I encourage my co-developers to talk to interfaces, and not implementations).

But why are estimates off anyway? Is it because (lack) of experience with the code? Even with code I’ve worked with for years I still made bad estimates. And I could not find a way to get them better. The newer project went way better for me to estimate. I already knew why it was going better:

My mental model of the code matched better to the actual code. Was it because I worked on it lately and knew how it worked exactly in detail? No, not at all! The Technical Debt is much lower on this project. One of the principles that played a huge rule was the Single Responsibility Principle (PDF). When I had to make a change, it was often in one place. When I had to add code, I could easily move code out of the class and seperate responsibilities. The code was less tangled, tightly coupled.

This phenomenom of untangling code, seperating concerns and having a hard time maintaining code is clearly a sign of repaying serious interests of technical debt. And I clearly see that as a result of a ‘choosen approach to solve the problem’.

Therefor I believe the technical debt is linked to essential and accidential complexity and even more (what about readability?). Accidential Complexity is something that is very hard to grasp. I think this ‘uncertainty’ needs to be clarified and be added to each initial estimate in order to get a ‘more realistic’ estimate.

I would recommend to estimate code while looking at the code itself, rather than use just your mental model of the code.
Finally, repaying the interest of the technical debt should be prioritized in order to be able to maintain the system and to prevent to get a mad customer getting ever less features using ever increasing time to make them.

EasyMock and Mockito, a little comparison

Someone mentioned a mocking framework called Mockito some time ago to me. I am familiar with mocking frameworks, as I work with EasyMock quite a lot. I really like EasyMock, but I am curious about Mockito. I thought of trying it out a bit and write down my experiences along with a comparison with EasyMock.

This is by all means not a very in-depth comparison, but I did find out some interesting things.

In order to test out the mocking frameworks I have set up some code in place to test. The code to be tested is an ‘itemRepository’ (It is however, not a full implementation of the Repository Pattern). Typically you use it to get some stuff (Items). In this case the Item is retrieved from a Dao object used by the repository. Just for easiniess the DAO returns the same object as the repository. (The repository pattern makes a distinction between the object the DAO returns and the Domain objects the Repository should return).

Here is the code of the ItemRepository:
[sourcecode language=”java”]
public class ItemRepositoryImpl implements ItemRepository {

private ItemDao itemDao;

@Override
public Item getItem(String someInput) {
return itemDao.getById(Long.valueOf(someInput));
}

public void setItemDao(ItemDao itemDao) {
this.itemDao = itemDao;
}

public ItemDao getItemDao() {
return itemDao;
}

}
[/sourcecode]

My goal is to test the ItemRepository’s getItem method. And all I care about is that the itemDao is correctly called with the correct parameters. Hence this is what a collaboration test is all about.

Lets start with my comfort zone: EasyMock

The test class I write talks to interfaces. I find it a good habit to talk against interfaces and not concrete implementations. Doing that however, forces me to cast to an implementation to set collaborators in the tests. Normally such things happen in the @Before. But since I will also create a test with the Mockito framework I have it done in the test method itself.

The begin of the test:
[sourcecode language=”java”]
public class ItemRepositoryTest {

private ItemRepository itemRepository;
private ItemDao itemDao;

@Before
public void setUp() {
itemRepository = new ItemRepositoryImpl();
}
[/sourcecode]

In line of the tripple A testing guidelines I have an arrange, act and assert:
[sourcecode language=”java”]
@Test
public void mustReturnItemFromMockedItemDao_EasyMock_Behaviour() {
ItemRepositoryImpl impl = getItemRepository();
itemDao = EasyMock.createMock(ItemDao.class);
impl.setItemDao(itemDao);

// this is weird: I don’t *want* to bother about returning stuff here, just that it is called!
// mocking and stubbing is combined here
EasyMock.expect(itemDao.getById(1L)).andReturn(null);
EasyMock.replay(itemDao);

// Act
itemRepository.getItem("1");

// Verify
EasyMock.verify(itemDao);
}
[/sourcecode]

As you can see I have pointed out one thing of EasyMock’s behaviours with a comment. Whenever you mock a method that has a return type, EasyMock expects you to fill in that behaviour. If you don’t do that, you’ll end up with an exception like this:

java.lang.IllegalStateException: missing behavior definition for the preceding method call getById(1)

In this case I have ‘solved’ it by returning null. While writing the test, I did not want to be bothered about it, but I have to satisfy EasyMock. Doing so reduces the readability of my code. The intention of the code remains unclear at this point, and that’s something I’d like to avoid as much as I can.

Another well known behaviour of EasyMock is the need to replay your mock after you have set the expectations. Using a ‘recorder’ metaphor it sounds reasonable. But basically you’re writing the behaviour ‘twice’: First you write down the expectations, then you actually run them. Writing the expectations is often found to be a cumbersome job to do, especially with multiple collaborators.

And of course at the end it all needs to be verified. Which is done by EasyMock.verify. We could even check the outcome. Most of the time you’re tempted to do so, you had to write the return value anyway. Better test if the return value being returned is the same as the method returns right? I think not. Reason: your intention of your test becomes unclear if you assert this as well. And as a bonus you introduce your tests to be more fragile. The unit test becomes now a collaborator test and a value-based test in one. Mockito makes this distinction very clear.

Mockito:
[sourcecode language=”java”]
@Test
public void mustReturnItemFromMockedItemDao_Mockito_Behaviour() {
// Arrange
ItemRepositoryImpl impl = getItemRepository();
itemDao = Mockito.mock(ItemDao.class);
impl.setItemDao(itemDao);

// Act
itemRepository.getItem("1");

// Assert / verify
Mockito.verify(itemDao).getById(1L);
}
[/sourcecode]

Plus:
– no need to mock return etc, as we dont care
– seperation of mocking and stubbing (stubbing is done by using the static method when, mocking by using verify).

So how about stubbing in Mockito? Here is how you stub the itemDao:

[sourcecode language=”java”]
@Test
public void mustReturnItemFromMockedItemDao_Mockito_Stubbing() {
// Arrange
ItemRepositoryImpl impl = getItemRepository();
itemDao = Mockito.mock(ItemDao.class);
impl.setItemDao(itemDao);

Mockito.when(itemDao.getById(1L)).thenReturn(null);

// Act
itemRepository.getItem("1");
}
[/sourcecode]

For more information about Mockito, they also have a more extensive comparison between EasyMock and Mockito.

Do you have any experience using Mockito and EasyMock and you would like to share some insights? Please leave a comment.

Someone pointed at RhinoMocks also being available for Java. I’m not so sure about that. However, if you do know about a Java variant, let me know so I can compare it as well.

How to fry your co-developers brain; and then make it better

Here is a little example of code I’ve been faced with (not written by me), that struck me. Although the syntax is correct (it is javascript), it took me a little while to actually understand what is going on.

Here is the code:
[sourcecode language=”javascript”]
someObject: function(data) {
return data.json ? data.json.stateObject ? data.json.stateObject : {} : {};
},
[/sourcecode]

And here is how I refactored it.
[sourcecode language=”javascript”]
someObject: function(data) {
if (data.json) {
if (data.json.stateObject) {
return data.json.stateObject;
}
}
return {};
}
[/sourcecode]

So I mentioned brianpower in a while ago. Michael Feathers though calls such a thing “forming a mental model“. Which is exactly what I meant. You also hear this in the scene of Usability; the less your mental model matches with the actual object you use (expectations), the less likely you’ll probably understand it, let alone *use it*.

So tell me, which one is easier to understand? And how much impact do you think this has?

Tiny refactorings? Compose Method!

I blogged about tiny refactorings not too long ago. I’ve even added an example showing such a refactoring in my game.

I’m reading Refactoring to Patterns, and figured that the refactorings I’ve mentioned have a name; it’s called the Compose Method. In the book it even has its own chapter (Chapter 7 “Simplification”), where it also refers to other great patterns to help you improve your maintainability of your code.