Status of encodingTests

[Øystein Grøvlen <Oy...@Sun.COM>]

What is the current status of encodingTests in the old test suite? 
DERBY-2568 mentions that it has been reported to be invalid.

The reason I ask is that when I run with locators for Blob, derbyall 
fails in TestPreparedStatementMethods.  This test has been converted to 
JUnit and called PreparedStatementTest.  I assume the reason it is still 
run in the old harness is the encoding tests.  In order to get derbyall 
to run without failures with locators, I would have to fix the same 
issues that I have already fixed for PreparedStatementTest.  That would 
be a waste of time if the encoding tests are not valid.

I guess I have three options:

1. Fix Blob lifespan issues in TestPreparedStatementMethods, and 
continue with two versions of the same test.
2. Disable TestPreparedStatementMethods (similar to what is done for 
LobStreamsTest in DERBY-2568).
3. Find some way that the Junit test PreparedStatementTest can be used 
for the encoding test, instead.

Since I am getting short on time wrt code freeze, I am tempted to go 
with the 2nd alternative. Objections?

--
Øystein

Re: Status of encodingTests

[Knut Anders Hatlen <Kn...@Sun.COM>]

Øystein Grøvlen <Oy...@Sun.COM> writes:

> Knut Anders Hatlen wrote:
>> Øystein Grøvlen <Oy...@Sun.COM> writes:
>>
>>> What is the current status of encodingTests in the old test suite?
>>> DERBY-2568 mentions that it has been reported to be invalid.
>>
>> I think there are strong arguments for removing the entire suite. It has
>> also been discussed in DERBY-2446.
>>
>>> The reason I ask is that when I run with locators for Blob, derbyall
>>> fails in TestPreparedStatementMethods.  This test has been converted
>>> to JUnit and called PreparedStatementTest.  I assume the reason it is
>>> still run in the old harness is the encoding tests.  In order to get
>>> derbyall to run without failures with locators, I would have to fix
>>> the same issues that I have already fixed for PreparedStatementTest.
>>> That would be a waste of time if the encoding tests are not valid.
>>
>> Is it still part of the encodingTests suite? derbynet/TestEnc.java is
>> the only test mentioned in encodingTests.runall.
>
> You are right.  My conclusions were wrong.  It turns out the test is
> run in the ordinary jdbc40 suite.  This suite is still run (both
> embedded and client) even if it seems all its tests have been
> converted to JUnit. I will file a JIRA for removing them.  Please,
> tell me if there is a good reason for still running them in the old
> test framework.

PreparedStatementTest was added in DERBY-1333, and the description of
the patch said:

  b) jdbcxa40.runall contains one entry as of now of the
  PreparedStatementTest.junit which is the TestPreparedStatementMethods
  test converted to junit and which is also added as part of this patch
  ...
  d) PrepaerdStatementTest.java which is the jdbc40 PreparedStatements
  converted to junit

I guess it was just an oversight that the old test wasn't removed.

-- 
Knut Anders

Re: Status of encodingTests

[Øystein Grøvlen <Oy...@Sun.COM>]

Knut Anders Hatlen wrote:
> Øystein Grøvlen <Oy...@Sun.COM> writes:
> 
>> What is the current status of encodingTests in the old test suite?
>> DERBY-2568 mentions that it has been reported to be invalid.
> 
> I think there are strong arguments for removing the entire suite. It has
> also been discussed in DERBY-2446.
> 
>> The reason I ask is that when I run with locators for Blob, derbyall
>> fails in TestPreparedStatementMethods.  This test has been converted
>> to JUnit and called PreparedStatementTest.  I assume the reason it is
>> still run in the old harness is the encoding tests.  In order to get
>> derbyall to run without failures with locators, I would have to fix
>> the same issues that I have already fixed for PreparedStatementTest.
>> That would be a waste of time if the encoding tests are not valid.
> 
> Is it still part of the encodingTests suite? derbynet/TestEnc.java is
> the only test mentioned in encodingTests.runall.

You are right.  My conclusions were wrong.  It turns out the test is run 
in the ordinary jdbc40 suite.  This suite is still run (both embedded 
and client) even if it seems all its tests have been converted to JUnit. 
  I will file a JIRA for removing them.  Please, tell me if there is a 
good reason for still running them in the old test framework.

--
Øystein

Re: Status of encodingTests

[Knut Anders Hatlen <Kn...@Sun.COM>]

Øystein Grøvlen <Oy...@Sun.COM> writes:

> What is the current status of encodingTests in the old test suite?
> DERBY-2568 mentions that it has been reported to be invalid.

I think there are strong arguments for removing the entire suite. It has
also been discussed in DERBY-2446.

> The reason I ask is that when I run with locators for Blob, derbyall
> fails in TestPreparedStatementMethods.  This test has been converted
> to JUnit and called PreparedStatementTest.  I assume the reason it is
> still run in the old harness is the encoding tests.  In order to get
> derbyall to run without failures with locators, I would have to fix
> the same issues that I have already fixed for PreparedStatementTest.
> That would be a waste of time if the encoding tests are not valid.

Is it still part of the encodingTests suite? derbynet/TestEnc.java is
the only test mentioned in encodingTests.runall.

> I guess I have three options:
>
> 1. Fix Blob lifespan issues in TestPreparedStatementMethods, and
> continue with two versions of the same test.
> 2. Disable TestPreparedStatementMethods (similar to what is done for
> LobStreamsTest in DERBY-2568).
> 3. Find some way that the Junit test PreparedStatementTest can be used
> for the encoding test, instead.
>
> Since I am getting short on time wrt code freeze, I am tempted to go
> with the 2nd alternative. Objections?

Given that it only runs under the jdbc40 suite and that
jdbc4.PreparedStatementTest has the same coverage (which seems to be the
case), I think option 2 is the best alternative.

-- 
Knut Anders