[jira] [Resolved] (GEODE-953) SerializableExternalResource and SerializableRuleChain should extend rather than borrow JUnit code

["Kirk Lund (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kirk Lund resolved GEODE-953.
-----------------------------
       Resolution: Fixed
    Fix Version/s: 1.0.0-incubating.M2

> SerializableExternalResource and SerializableRuleChain should extend rather than borrow JUnit code
> --------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-953
>                 URL: https://issues.apache.org/jira/browse/GEODE-953
>             Project: Geode
>          Issue Type: Bug
>          Components: tests
>            Reporter: Kirk Lund
>            Assignee: Kirk Lund
>             Fix For: 1.0.0-incubating.M2
>
>
> The override hooks that JUnit Rules provide allows a "before()" method to throw any Throwable (including checked exceptions), but does not allow an "after()" method to throw checked exceptions. See below:
> {noformat}
> protected void before() throws Throwable {
> protected void after() {
> {noformat}
> The currently committed versions of SerializableExternalResource and SerializableRuleChain borrow code from JUnit instead of extending JUnit classes to allow changing the after() to have a throws clause:
> {noformat}
> protected void after() {
> {noformat}
> If we choose to follow the JUnit best practice of having after() not perform any verifications (or otherwise be a very safe call that cannot throw checked exceptions), then we can change these classes to extend the JUnit classes instead of borrowing any code from JUnit.
> The Transaction and Off-Heap dunit tests should be changed to NOT perform any assertions during tearDown()/after(). There may be additional DUnit and JUnit tests that also need to change to bring them into line with the best practice
> Checked exceptions can also be wrapped in an Error or RuntimeException so this "limitation" could theoretically be worked around if necessary.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)