db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5726) Make it more difficult to forget calling super.tearDown() from BaseJDBCTestCase's subclasses
Date Mon, 14 May 2012 10:10:48 GMT

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

Knut Anders Hatlen commented on DERBY-5726:
-------------------------------------------

If someone wants to run the tests with limited amount of memory, it might make more sense
to have a way to disable known memory-hungry tests, as forking the tests would still require
much memory in the sub-process. I'm not sure we'd want to introduce a hard limit on 64MB for
running suites.All, though, as that was a number I picked rather arbitrarily to smoke out
the leaks.
                
> Make it more difficult to forget calling super.tearDown() from BaseJDBCTestCase's subclasses
> --------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5726
>                 URL: https://issues.apache.org/jira/browse/DERBY-5726
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>    Affects Versions: 10.9.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>             Fix For: 10.9.0.0
>
>         Attachments: d5726-1a.diff
>
>
> Many of the classes that extend BaseJDBCTestCase and override the tearDown() method,
forget to call super.tearDown(), and thereby prevent resources from being freed after completion.
We should add a mechanism that enforces the correct behaviour.
> If we were starting from scratch, we might have made BaseJDBCTestCase.tearDown() final
and added a new overridable method that was called from BaseJDBCTestCase.tearDown() before
it freed the statements and connections. Then there would be no way to prevent BaseJDBCTestCase.tearDown()
from running in the subclasses. That would however require us to change all existing overrides
of BaseJDBCTestCase.tearDown() (current count: 131), which would be a chunk of work.
> I'd rather suggest that we add an override of runBare() in BaseJDBCTestCase that asserts
that the connection has been cleared out when a test case has completed successfully. Something
like this:
>     public void runBare() throws Throwable {
>         super.runBare();
>         // It's quite common to forget to call super.tearDown() when
>         // overriding tearDown() in sub-classes.
>         assertNull(
>             "Connection should be null by now. " +
>             "Missing call to super.tearDown()?", conn);
>     }
> Then it would still be possible to forget to call super.tearDown(), but it would be discovered
when trying to run the test.
> Adding the above method to BaseJDBCTestCase and running InternationalConnectTest gave
this result:
> .....F.F....F
> Time: 5,748
> There were 3 failures:
> 1) testDriverManagerConnect(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
Connection should be null by now. Missing call to super.tearDown()?
> 	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 2) testBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
Connection should be null by now. Missing call to super.tearDown()?
> 	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
> (...)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message