db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
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:44:44 GMT
thanks for the great explanation.

 -jean

Daniel John Debrunner wrote:
> 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