I gave up.  I finally closed the comments on this Java Projects entry that kept receiving comments from Indian students who don’t bother reading what they are commenting on.  I think there are more than two hundred (200!) comments from students asking me for project ideas by now.  I didn’t close the comments initially because I wanted to see how far the insanity could go…  Well, very far it seems, and no end in sight.

Updating the entry to point visitors to a clarification didn’t change anything:  the requests for project ideas kept coming at the pace of about one per day, so I decided to put an end to it.

Except that…  my Movable Type installation is using Berkeley DB, and there is no way to close comments or trackbacks for past entries (or do any kind of batch operation for that matter).  The only way was to move it over to MySQL, which ended up being surprisingly easy.

The first thing to do is to download Movable Type 3, which contains a very handy mt-db2sql.cgi script.  That’s all you need from Movable Type 3 and this script works on Movable Type 2 (the one I’m using).  All you need to do is put this script in your installation directory and follow the instructions.  The script took a few minutes to run (I have over three hundred entries by now, several thousand comments and the script transfers everything, including the logs, which I couldn’t care less for) but it completed successfully and after that, I was migrated.  As simple as that.

My MT-BlackList installation was disabled during the process, but reactivating it was a simple matter of going to the main page and checking a box.

I connected manually to the MySQL database to double check and everything worked like a charm.  The schemas are very intuitive and a few SELECT, UPDATE and WHERE later, I had closed the comments for the offending entry and also the trackbacks for all my past entries (the latest trend used by spammers, which shows at least that CAPTCHA’s are working fine).

Sorry, India, you’ll have to look somewhere else for Java projects.

The
first version of the TestNG
IntelliJ plug-in is now ready for testing. 

This is a joint work by Mark and Hani, who’ve been pulling all the
stops these past days to get the plug-in ready.  There is more work going
into the plug-in as we speak, but it’s ready for a first round of testing,
so try it and post your feedback on the
TestNG user
mailing-list or here.

Thanks
a lot to Mark and Hani, and also to Alexandru whose original Eclipse plug-in
code was instrumental to getting this plug-in finished (and which also paves
the way for future plug-ins).

Great
job guys!

My answer to the question “Should you test private methods” is a resounding YES!

Let me start by giving you two examples.

Imagine that you are writing a Swing table widget that lets you order your columns in several different ways. Your sorting algorithm is private and one day, you introduce a bug in it. If all you do is test the public methods, the widget will simply start showing wrong results and your tests won’t tell you anything more. For all you know, there might be a bug in your Swing code. If you unit test your (private) sorting algorithm, you will catch the error right away instead of wasting time “higher up the stack”.

While this first example is fictitious, this second one is from TestNG itself.

TestNG uses a partial ordering algorithm to determine in what order methods should be invoked. Methods that have no dependent can be invoked at any time but methods that depend on others (or that are depended upon) need to be invoked in a certain order. This requirement creates a “partially ordered set” of methods, which means that some of its elements are ordered but not all.

This algorithm is completely private, but if it goes wrong, TestNG will start failing in very mysterious ways, indicating dependency failures and other strange error messages. It was pretty obvious to me that I needed a separate test for this section of the code.

I am sure that anyone can relate to a similar situation where their code was so dependent on a private section of code that it was vital to make sure that you would know right away if this part should break.

When it comes down to testing, I follow a very simple rule: “if it can break, test it”.

Now that we have determined that there are actually two kinds of testing (private and public), I would actually go one step further and argue the following points:

• Private tests should run before public tests.I don’t think there is much point in running your public tests if some of your private tests are failing. When private tests fail, the entirety of your code might be jeopardized and will probably fail in random places or maybe even pass in places where it should fail. This situation is a little bit like using a compiler that generates invalid code: wouldn’t you try to fix the compiler before you try to compile any program with it?
• Private tests should prevent public tests from running if they fail. This is a consequence of the first point. If your private tests fail, you might as well save yourself the trouble of spending time running your public tests since they will be meaningless.
• Private tests should be listed first in the reports. If some of your private tests fail, they should be the first thing you investigate since fixing them might actually fix the potential failures in your public tests.

Since TestNG supports dependent testing (“don’t bother running test method b() if test method a() didn’t succeed”), it might actually be interesting to add a way to specify that a certain test is testing your private API. This way, TestNG would run it first and make all other non-private tests depend on it…

What do you think?

This feature has probably been in Eclipse for a while but I only recently
discovered it, and I’ve found it quite useful already:  Eclipse lets you
define launch configurations that depend on the current selection.

Consider the simple following program that prints out the parameter passed on
the command line:

public class Echo {
  public static void main(String[] args) {
    System.out.println(args[0]);
  }
}

Then create a launch configuration and press the Variables button:

Choose the variable "selected-text":

And close the launch dialog.  Next select some text in a buffer, say the
first line of the class:

Launch, and you get:

public class Echo {

I have used this feature quite a few times already to launch groups of tests
with TestNG by simply selecting them from my Java source or the XML file, but I’m sure there are many other uses.

There are plenty of other interesting variables to choose from, by the way,
try them out and report here!

The TestNG team is happy to announce the release of
TestNG 2.4.

A lot of fixes and improvements have gone into this release (see the

complete list) but the most important feature is the new Web site (http://testng.org)
and the new packaging (org.testng.*).

There are also a couple of items I want to mention briefly:

• A
  
  Flash demo of the Eclipse plug-in, created by Andrew Glover (who also
  set up a
  
  TestNG site with articles and resources).
• A
  TestNG Maven plug-in.  I couldn’t include it in this release, but
  it is now part of our CVS depot and will be included in 2.4.1.

Big thanks go to Alexandru Popescu, Andrew Glover, Thierry Janaudy and Russel
Winder for their participation to this new release!

You can download TestNG 2.4
here.  The Eclipse plug-in has also been updated to this new version
and can be obtained from the update site (http://beust.com/weblog/eclipse).