Recently I have created 2 tests for two classes that looked very similar. Well, they were same apart for testing different subclasses of the same parent. Indeed, tested classes were also similar. I have to fix this (on both sides if possible).

I have found this problem when I wanted to introduce new method to interface and was adding test for it. So my first idea was to reuse test implementation for both classes by creating abstract test and two subclasses handling different initialization of tested classes (different class to instantiate and also different colaborators). Problem is that these two classes together with their tests are not located in the same module. Natural place for abstract test is to put it into module that contains interface, because it is basically testing contract of that interface. Then add concrete tests into modules that implement interface. However our build system does not allow me to do that because tests are not part of built artefact, thus dependent modules do not see them.

A workaround for this problem is to introduce a new module that will contain abstract test masked as production class, hence it will be visible from other modules. Of course, this new helper module will not be included in installer of product. All problems solved... Not so fast, theoretically this works perfectly, but it might not be practical if that new module would contain only 1 or 2 abstract tests. It is heavy weight solution for such amount of code. Our codebase contains tens of small modules separating different parts of product to abstract and concrete modules (which is good) and introduction of test-supporting modules might help this number to grow rapidly.

Fortunatelly I have found that I can solve this particular problem differently this time, because only occured due to badly factored production classes. If I create abstract superclass for them, I can easily remove duplication of tests and add new test classes testing only logic that is different.

Somehow I am getting different moral conclusion that I planned with this post - "Look for real source of problems before attempting to fix them", but that's only because my case was special. In general, it is important to "Make sure your build system allows you to depend on tests from different modules" (only tests should depend, not production code). This allows you to do better tests regarding removing duplication by factoring common code to helpers and introduction of abstract interface tests.

Note about testing of intefaces

I was not able to google good example of inteface tests (Apart from that you can read about them in JUnit Recipes by J. B. Rainsberger, but that will not help you to get up to speed without having the book at hand. Still I encourage you to read it later.). So I am going to write a few lines about the idea. Let's have interface Stack.

public interface Stack {
    void push(Object data);
    Object pop();
    boolean isEmpty();
}

This interface has defined contract. It can be specified as Javadoc or any other way, but how can you make sure that all implementations comply to it?

The best way to achieve compliance is to provide abstract test case that implementor extends and provides method for creation of tested instance. Then she can execute test and everybody knows if it is compliant or not in fraction of second.

public abstract class StackTest {
    protected abstract Stack createInstance();

    public void testShouldPopLastPushedItem() {
        Stack tested = createInstance();
        //... rest of test
    }

    public void testShouldThrowExceptionWhenPoppingFromEmpty() {
        Stack tested = createInstance();
        //... rest of test
    }
}

Having these tests for contract it is quite easy to verify our cool implementation of Stack is working:

public class PersistentAndsSecureStackTest extends StackTest  {
    // add some setUp and tearDown if needed
    protected Stack createInstance() {
        return new PersistentAndsSecureStack();
    }
}

Back to the point

This is only one of the reasons why my tests need to be able to depend on tests from other modules. It is simply strong tool for making sure product is well tested and all duplication is removed.

I am still not able to set up dependency of tests between different modules. Fortunatelly I did not need it again.

Recently I was trying to help my younger colleague with preparation of list of topics what he should learn. Well, it was my idea to provide such a list to him, I am not really sure if he was really interested in short term as his highest priority now is Java certification. My list included following:

• OOP
• design (principles)
• design patterns
• TDD
• refactoring and how to identify code smells
• writing expressive code

My list did not contain Java, but I added "look into other languages like Ruby, Lisp, Erlang to get an idea there are more possibilities" just to show my bias towards skills that can be used also after changing implementation language. Still I believe language/libraries details are important, but it is easy for me to say that after mastering advanced topics in Java many years ago.

Then I've realized it is huge task list as none of those topics can be learned in "a week". Even worse, I am not able to prioritize them to help tackle this daunting task. My best offer is along the lines "learn everything at the same time".

I have to say I am really glad not being in the same position, that I need to learn everything again. It hurts just to imagine what I would need to learn. Of course, I still need to grow in all areas (as most of us), but it is easier to select some topics that interest me more just now and go through them without a rush. Or to jump from one topic to another.

Recently I have logged into internet banking application of my bank in Slovakia. I found an ad offering me a loan. That is fine, I like to be informed about potentially useful things. This time, however, I was not interested. But I could continue only with two paths "Contact me, I am interested" and "Show me this offer later". This looked like unintentional omission of third possibility "Thank you, do not show me this again". So I contacted the bank and told them about this.

I've got reply next day (yes, they have good customer service). From the answer I have learned that that option was there before, but sometimes people clicked "I do not care" and then, some time later they wanted to apply. So the bank decided to solve this glitch. And they did. Problem is, that solution seems worse than original problem. People not interested in that offer in current version of internet banking are supposed to click "Contact me, I am interested", that will present them a form they need to fill out. The critical part is to leave the form empty. That handles missing state "Thank you, do not show me this again" with possibility of changing your mind later, because empty form will be available in "empty forms" folder.

Huh? How was I supposed to figure that out? And what about people that do not keep in their mind that you need to click Start if you want to shutdown Windows? I do not know what designers/programmers in my bank were thinking about, but I expect I am not the only person who would not click "Contact me" option if I do not want to be contacted. It seems to me that someone suggested the cheapest technical solution how to add new this new functionality - just remove existing feature and existing code will handle rest of it. I am sure they did not think about people using their product.

I hope it is only workaround until they implement, test and deploy working solution.

I started to develop my Photoblog about a half year ago. In the beginning I just wanted to try Rails and the best fit was to start with photo publishing application that I needed at that time. It was killing two birds with one stone, because I was not aware of any existing blogging application that would fit my needs. I wanted to publish many photos associated with prose-like text so galleries were out of question and blogging applications I've tried were clumsy regarding uploading many photos. But maybe the biggest excuse to do it myself was Rails :-) In the beginning I did not use any VCS. List of excuses contains following:

• I am just playing with Rails
• I am lazy to learn how to install Subversion on Win or force my brother that hosts the application to install it to FreeBSD.
• app is not big enough to deserve VCS

Of course there were consequences:

• fear of breaking it with too many changes and not being able to get back
• all changes need to be small in order to avoid mentioned fear
• (never needed for this blog, but I do it often in work) no history for artefacts. If something looks strange I like to check history to see how I got there
• once deployed, unable to get back easily. You can imagine how often my production environment caused previously unseen problem. When that happened I needed to work fast to resolve it in production, because it was often easier that manual rollback to previous state

Recently I have adopted Mercurial. It is very easy to install, easy to use (I still have to undestand more complicated things regarding distibution of partial changes and merges of complicated setups), but has a few disadvantages like unfinished suport for Intellij IDEA and no merging tool. Still it is more than sufficient for my current needs. Now I can:

• revert in case of messed code, wasting only time it took me to mess it, but not more.
• explore new features without a need to finish previous one - I started to do gallery-like navigator in parallel with changes in layout, exploring different layouts and finally started to implement this IT blog, gallery and more. When I am happy with some feature and I like to move it to production, I just push to to main repository and merge.
• do very easy rollback in production if I find "it will not be as easy as I thought to put it into production, but I do not have time to finish it immediately" (it might need keeping migrations correct and tested, but otherwise it is matter of hg revert 53

List of my favorite commands follows:

• hg clone source dest
• hg status
• hg ci
• hg up
• hg push
• hg revert

Here is link to Mercurial http://www.selenic.com/mercurial/wiki/

Point of this post is: "Listen to those telling you to use VCS for even smallest projects you do. They know what they are talking about".

I nearly forgot. I found about Mercurial (mainly how easy is to install it) thanks to Stephan Schmidt's blog here http://stephan.reposita.org/

When I was thinking what should be my first post in my new professional blog I have remembered test method (in one undisclosed code base) I have seen a few months ago. It was test for equals(). Rather amusing one, clearly not doing what it was intended for. (I have changed it a bit to protect author and I should state that it was written years ago, thus its author does not do these things anymore).

    public final void testEqualsObject() {
        final SomeObject objOne = // new ...
        final SomeObject objTwo = // new ...
    
        final SomeObject tmpObj = objOne;

        assertTrue("The equals() failed", objOne.equals(tmpObj));
        assertFalse("The equals() failed", objOne.equals(objTwo));
    }

That assertTrue can test only default implementation of Object.equals that uses ==, but nothing more. assertFalse is a bit better, but not enough for quite complicated contract equals and hashCode have.

I have fixed it, unfortunatelly not in way I would like to - by usage of EqualsTester, because this and all other implementations of equals() use instanceof that is controversial enough to start fighting about right now.

Do me a favor, any time you need to test equals and hashCode use EqualsTester, please. You will not regret it in the long term.

What is the most useless piece of unit test you have seen? Your code done in past counts too ;-) How did you fix it?