geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-953) SerializableExternalResource and SerializableRuleChain should extend rather than borrow JUnit code
Date Tue, 01 Mar 2016 00:10:18 GMT


ASF subversion and git services commented on GEODE-953:

Commit 5342935d301a4026b289637885e9236414feeb78 in incubator-geode's branch refs/heads/feature/GEODE-949-2
from []
[;h=5342935 ]

GEODE-953: Cleanup geode-junit

* cleanup geode-junit usage of JUnit Rules to ensure JUnit code is always extended rather
than copied
* change CRLF to LF
* remove @author tags
* fix all javadocs
* fix formatting
* add new tests
* remove ExpectedTimeout and ExpectedTimeoutTest (they were dupes of ExpectedTimeoutRule and
* use serialization by reflection for serializable subclasses of JUnit rules that lack sufficient
ability to subclass
* repackage rule tests to same package as rules
* repackage serializable rules into serializable sub-package

> SerializableExternalResource and SerializableRuleChain should extend rather than borrow
JUnit code
> --------------------------------------------------------------------------------------------------
>                 Key: GEODE-953
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: tests
>            Reporter: Kirk Lund
>            Assignee: Kirk Lund
> 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

View raw message