db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: JUnit common methods & assert messages WAS Re: [jira] Commented: (DERBY-827) Performance can be improved by re-using language ResultSets across Activation executions.
Date Mon, 05 Mar 2007 17:22:00 GMT
Jean T. Anderson wrote:
> Daniel John Debrunner wrote:
> ...
>> This style of code
>> can be expensive at runtime:
>>    for (int i = 0; i < count; i++) {
>>       assertEquals("Testing at iteration " + i, f(i), g(i));
>>    }
> 
> I'm a fresh guinea pig eager for advice ....

The issue with the example above is the message
   "Testing at iteration " + i

This compiles down to code something like:

   StringBuffer sb = new StringBuffer("Testing at iteration ");
   sb.append(i);
   sb.toString();

That's a minimum creation of three objects (StringBuffer, char[] and 
String) and at worse five (two more char[]).

Thus some executed code and several object creations for a string object 
  that is never used (because tests don't fail in the common case).

> 
> In CallableTest.java I have this:
> 
>     for(int i=0; i< updateCount.length; i++){
>         if(i == 1) // The second command in the batch failed.
>             assertEquals("Batch updateCount", -3, updateCount[i]);
>         else
>             assertEquals("Batch updateCount", -1, updateCount[i]);
>     }

In this example the string message is fixed, so there's no problem with 
the overhead. Assuming the message was something like:

    "Batch updateCount at " + i

then the following does make sense. Though I'm not sure it's better, it 
seems to me to be less clear. I'm not sure of a good solution here. 
Maybe performance of the tests is not critical, but then again the 
faster the tests run the better it is for everyone. One issue is that 
how critical is it to have a variable message? If such a failure is 
expected to be very rare (as we hope) then maybe the best solution is to 
have who ever looks at the test add extra debugging information when 
they are investigating a failure.

> would this be advised?
> 
>     for(int i=0; i< updateCount.length; i++){
> 
>         if( (i == 1) && (updateCount[i] != -3) )
>             assertEquals("Batch updateCount", -3, updateCount[i]);
>         else if (updateCount[i] != -1)
>             assertEquals("Batch updateCount", -1, updateCount[i]);
>     }

Dan.



Mime
View raw message