[jira] Commented: (DERBY-3663) Convert store/streamingColumn to JUnit

["Kathey Marsden (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599249#action_12599249 ] 

Kathey Marsden commented on DERBY-3663:
---------------------------------------

Here are some comments.  I will look more on Monday.  
Probably already have these on your list.
 - add test to suite.
- remove from derbyall and cleanup old test files.

Comments on StreamingColumnTest
- It's a failing of the original test, but it would be great to have some javadoc comments for the fixtures.

- The unused method private static void expectedException1(SQLException sqle) can be removed.

-- basesuite()
- In basesuite we have 
	TestSuite suite = new TestSuite(name);
		suite.addTestSuite(StreamingColumnTest.class);
		Test test = new SupportFilesSetup(suite, new String[] {
				"functionTests/tests/store/short.data",
				"functionTests/tests/store/shortbanner",
				"functionTests/tests/store/derby.banner",
				"functionTests/tests/store/empty.data"} );
		return new CleanDatabaseTestSetup(DatabasePropertyTestSetup
				.setLockTimeouts(suite, 2, 4)) {

Shouldn't it be test and not suite that gets passed to CleanDatabaseTestSetup?


-- testStream1()

- We have:
	try {// if trying to insert data > 32700, there will be an
					// exception
					ps.executeUpdate();
					println("No truncation and hence no error");
				} catch (SQLException e) {
					if (fileLength[i] > Limits.DB2_LONGVARCHAR_MAXWIDTH) {
						assertSQLState("22001", e); // was getting data longer
						// than maxValueAllowed
						println("expected exception for data > "
								+ Limits.DB2_LONGVARCHAR_MAXWIDTH
								+ " in length");
			\
There should be a fail(....) after the ps.excecuteUpdate for the cases where we expect an exception.

- I know it was part of the original test, but it seems strange that the test imports and uses mport org.apache.derby.iapi.reference.Limits.  Typically the test code does not use the engine code.  Perhaps we could use constants in the test insteadx.


--testStream2*() 
- I feel a little funny about the duplicate code in testStream2_1500, testStream2_5000 and testStream2_10000.  Could you extract some of the code and have a 
testStream2(long length, String tablename) that you call from these methods?


-- testStream3*()
- Same comment about duplicate code.
- Statement sourceStmt = createStatement(); is not needed

-- testStream4()
- local variable met is not used.
- you can remove the catch and throw of the exception since the method already throws Exception.
- one thing that is funny is that the results that are processed don't seem to be checked at all.  This is a carryover from the original test, but at least perhaps we could check the columnSize.




> Convert store/streamingColumn to JUnit
> --------------------------------------
>
>                 Key: DERBY-3663
>                 URL: https://issues.apache.org/jira/browse/DERBY-3663
>             Project: Derby
>          Issue Type: Test
>          Components: Test
>            Reporter: Suran Jayathilaka
>            Assignee: Suran Jayathilaka
>         Attachments: derby-3663-1.diff
>
>
> Convert org.apache.derbyTesting.functionTests.tests.store.streamingColumn to a JUnit testcase.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.