Wednesday, August 26, 2009

JUnit: How to test your private methods

Some weeks ago I was creating some unit tests for a hobby project I'm working with. But I found myself stuck trying to test some private methods.

My first though was "Should I even need to test those methods?" I invested some time looking for alternatives, but those methods must be private. What could I do?

One option was to modify those methods to be public, anyway this is a hobby project and I know I'm not going to call them from outside. But since the main reason of this project is to learn I though I would best invest the needed time to find the correct solution.

Being a fan of the Java reflection API, I decided to investigate this approach. This is the result:

* Convenient method to execute private methods from other classes.
* @param test Instance of the class we want to test
* @param methodName Name of the method we want to test
* @param params Arguments we want to pass to the method
* @return Object with the result of the executed method
* @throws Exception
private Object invokePrivateMethod (Object test, String methodName, Object params[]) throws Exception {
Object ret = null;

final Method[] methods =
for (int i = 0; i < methods.length; ++i) {
if (methods[i].getName().equals(methodName)) {
ret = methods[i].invoke(test, params);

return ret;
As you can see the code is simply doing the next steps:
  1. Retrieve an array of declared methods
  2. Loop the array looking for the method we want to test
  3. Once found, set the method as public
  4. Execute the method and return the result
And we want to use it, we only need to do something like:
MyClass instance = new MyClass();
String expResult = "Expected Result";
Object[] params = {"A String Value", "Another Value"};
String result = (String) this.invokePrivateMethod(instance, "myPrivateName", params);
assertEquals(expResult, result);
This is the best I could find. Fair enough but, do you know of a better or more elegant solution?

See you soon.

Monday, August 24, 2009

Can I do 'this' with my favorite language?

When we need to start a new project we use our favorite language by default. Is it wrong? The short answer is "No, it's not wrong". But the correct answer is a bit more complex.

Before starting a new project we should answer some basic questions.
  • Is our project a desktop or a web application?
  • Do we need a user interface?
  • Should it be cross-platform?
  • Do you need to integrate with some external service/platform?
Answer these points and now think for a couple of minutes if your favorite language is good enough.

Almost all the "
General Purpose Languages" (and here) are good enough to do any kind of application, but there are cases where it is much better to use some "Domain Specific Language" or, at least, a different language that is better suited to do the specific kind of application we want to do.

Let's see some extreme examples:
  • If I need to create a program to automatize my connection to different SSH server, I could do it in Java, but that would be overkill, and too complex. A simple BASH script will be faster and easier.
  • If I'm a PHP developer and I need to create some simple desktop application. What should be my choice? Sure I can compile PHP code into an exe file, but probably I would get a much better and faster solution using Java, C# (or any other .NET language) or even Python.
  • As I said, these are radical examples, but I think that shows my point. Don't be lazy when choosing the language you need. Even when a lot of languages would be OK to solve the problem, maybe your choice is not the best one.
See you soon.

Sunday, August 23, 2009

Keep performance in mind

Almost anywhere you will find that your first step when coding is making it to work and only later worry about performance. I only half agree.

It's true that your code must work, otherwise you'll have nothing. But while you're coding you must always keep in mind the performance of this code. I don't mean that you should invest extra time trying to make your code faster, you just need to keep in mind some general recommendations about performance that will help you.

For Java developers, this is a good checklist, but most of them are valid for almost any language:
  1. Do not recalculate constants inside a loop.
  2. Reduce the number of network operations by returning complete results rather than smaller intermediate results.
  3. Reduce the distance between objects during operation. It is better to perform complex operations locally.
  4. Avoid object creation and destruction except as necessary. Reuse existing objects.
  5. Use open source frameworks which are established and tested.
Find a list of performance check points for your favorite language and keep it in mind.

See you soon.

Thursday, August 20, 2009

Don't understimate the need of tools

Hi again,

When we choose a language/framework/platform to start a new project we usually think that we'll have all the tools that we need. False. Doesn't matter what we do, we'll always need a new tool that doesn't exist in the market to solve some problem.

Ten years ago I was working in a company using C/C++ in a cross-platform product (Windows, Solaris and Linux). I though that I would find absolutely anything I would need "I'm working with C, everything is available" And I was almost right, I found almost anything I needed, but almost none of them were cross-platform. At the end of the day I needed to create my own cross-platform API.

Six years ago I worked for another company where we worked mainly with Java. Then I though "Great, Java is cross-platform I will have no problems" you know what? I was wrong. We were mainly working with code stored in an Oracle Database Server, together with thousand of string literals for the User Interface in multiple languages (Spanish, English, French, German, ....) And we also wanted to move from Java 1.3 to Java 1.4 (I know, but was an enterprise system) On top of that there was no way of compiling everything, since the code of every single operation was stored in the Database, so no real source files were available.

So at the end of the day I needed to create a data mining tool to spell check all the strings from the Database, also was capable of retrieving and compile the code of every operation to check if it could compile properly and detect deprecated code (so I could simulate the migration to Java 1.4) and also look for other potential problems merging my tool with FindBugs and CheckStyle.

Four years ago I started to work for my actual company. There I was expecting anything. The main language was Tcl/Tk. I was wrong again, now was a matter of creating almost any tool that I would need, since Tcl is one of the less used languages in the world and I'm working in what's probably the biggest application wrote with it.

What have I learned from all these cases? Doesn't matter which technology do you use, at the end of the day you'll need to write some tools to solve unexpected problems/situations.

And don't be lazy about it. These tailored tools will always help you, so don't leave them for later.

See you soon.

Monday, August 17, 2009

Is it possible to finish a hobby project?

I've seen this scenario tons of times, both in colleagues and myself.

When I am working in a real project (paid for) I have a full project roadmap, I set deadlines and I work focused in the project. But when I start some hobby project it's never finished, I'm never satisfied by its quality, why?

So far I have detected the next problems:
  • I focus only in the most appealing features to me, and not in getting something working
  • I can rarely invest quality time or work more than a few hours in the project
  • There's no external pressure
  • I use my hobby projects to experiment with new technologies, so sometimes I write the same program with different languages and/or libraries.
What should I be doing?
  • I should define a minimum set of features and focus on them before jumping to more fancy and funny stuff
  • I should work on my projects only when I can really invest time (vacations, weekends)
  • Put deadlines and give me a prize if I make it
  • Experiments are great and needed, but I should do them one by one and not try to test multiple things at the same time
What do you think? What are your tips?

See you soon.

Sunday, August 16, 2009

Good Support is Important

As developers we usually think that our code is the most important part of the product. We focus in getting the best possible piece of code, fast and bug free. Sadly there's no such a thing like "bug free" software (in fact there's no such a thing like "problem free product". When shit happens then is the turn of our support colleges to solve the problem.

A good support department will make the customer forget about the real problem and be happy for the great help he received. And that's really important if you want to keep your clients/customers happy and loyal to your product.

I'm lucky enough to work in a company where the support department is really friendly and our customers love it. Doesn't matter which kind of problem do they have (bug, feature request or simply a question about how to use our software for an specific task) our support department is always there to help and find some solution or workaround.

But let me talk about a especific issue I had some days ago with my wife's laptop.

In January I bought for her a Dell Studio 17 laptop. Nice computer, fast, big screen. She loved it. But just 2 weeks ago the screen started doing funny stuff. I did some checks and finally concluded that the problem was with the monitor, so I was decided to complain to Dell support about the shitty monitor that broke down in just 8 month.

I phoned, and as soon as I explained my problem, the support guy politely asked me to run some tests through the bios. After that he told me that they would send me home a tech guy within the next 5 working days. The next day I got a call from Dell to coordinate when it would be for me the best time for them to come, so we schedule it for Saturday (2 days later), between 9:00 and 13:00. I was sure I was going to waste the whole Saturday morning waiting for the guy.

Saturday 9:30 I got a phone call from the tech guy to confirm that I was at home. He arrived 30 minutes later with a brand new monitor. Unplugged the damaged one, connected the new one and ask me to check if everything was working properly. Everything was fine :) Even better 3 days later I got another call from Dell to check if everything was still working fine and if I was happy with the tech guy that came to do the fix.

So basically I got a damaged monitor replaced by a new one in less than 4 days. The tech guy came to my home and I didn't pay a cent. And then I realized that my next laptop is also going to be a Dell, why? Because shit happens, any piece of any machine of any manufacturer can break down. But Dell can fix it in just a few days and with a friendly and helpful group of people.

That's why I think that a good support department is important. Because they can change a potential angry customer into a happy and loyal one.

See you soon.

Hello World

Saying "Hello World!" is probably the best way of starting a new blog about programing. But why a new one? We can find thousands of blogs out there, but I have the impression there's a gap that needs to be filled.

My name is Carlos and nowadays I live in Majorca, Spain, but I've lived also in Barcelona and Hanover (Germany). I've worked as Software Engineer the last ten years, and this is the first time I write a blog.

Working in different countries, cities and companies gives an interesting overview about what's important and what's not (or at least what I think it's important). For years I've been reading blogs finding, from time to time, really good comments and appreciations, but rarely I've found a blog where I can identify myself.

In this blog I'll try to share my point of view about things, without being too technical. And I really hope that you'll find it interesting. I'm also hoping that other people is going to collaborate and comment here adding their comments, experiences and ideas.

I really hope you will like the contents of this blog.

See you soon