[jira] [Comment Edited] (SLING-8114) Allow to do polling of code failing on asserts

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Comment Edited] (SLING-8114) Allow to do polling of code failing on asserts

JIRA jira@apache.org

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

Valentin Olteanu edited comment on SLING-8114 at 12/4/18 1:05 PM:
------------------------------------------------------------------

[~petitbear68], I (partially) like the DSL provided by {{awaitility}}, but I wouldn't include it in {{sling.testing.clients}} because it brings too many dependencies (junit, hamcrest), which we kept away on purpose and moved the related classes to {{sling.testing.rules}}.
Including it would also mean exposing all its classes as part of our API, so we would be susceptible to breaking changes introduced by new versions. But we _could_ introduce a similar DSL to {{Polling}} :D

Back to the original problem, [catching Throwable is a bad practice|https://stackoverflow.com/questions/6083248/is-it-a-bad-practice-to-catch-throwable], especially for {{Error}} s. So I wouldn't even add this, but change the test code to throw another exception (why not {{ClientException}} ?). I suppose we need to better document this in the Polling.

Note: I just realised we are already too greedy with catching {{Exception}} and we should re-throw {{InterruptedException}} - created SLING-8160 for this.


was (Author: volteanu):
[~petitbear68], I (partially) like the DSL provided by {{awaitility}}, but I wouldn't include it in {{sling.testing.clients}} because it brings too many dependencies (junit, hamcrest), which we kept away on purpose and moved the related classes to {{sling.testing.rules}}.
Including it would also mean exposing all its classes as part of our API, so we would be susceptible to breaking changes introduced by new versions. But we _could_ introduce a similar DSL to {{Polling}} :D

Back to the original problem, [catching Throwable is a bad practice|https://stackoverflow.com/questions/6083248/is-it-a-bad-practice-to-catch-throwable], especially for {{Error}}s. So I wouldn't even add this, but change the test code to throw another exception (why not {{ClientException}} ?). I suppose we need to better document this in the Polling.

Note: I just realised we are already too greedy with catching {{Exception}} and we should re-throw {{InterruptedException}} - created SLING-8160 for this.

> Allow to do polling of code failing on asserts
> ----------------------------------------------
>
>                 Key: SLING-8114
>                 URL: https://issues.apache.org/jira/browse/SLING-8114
>             Project: Sling
>          Issue Type: Improvement
>          Components: Apache Sling Testing Clients
>    Affects Versions: Apache Sling Testing Clients 1.2.0
>            Reporter: Thierry Ygé
>            Priority: Major
>
> Currently if you polling check uses assertions , it will not be retried, this is due to this line
> [https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/poller/Polling.java#L118]
> Which is only catching Exceptions while failing Assertions are an error kind (AssertionError).
> It would be nice to handle it so that code wouldn't have to "transform" it to exception.
> To reproduce simply use assertion in your polling check and let it fail if a counter is lower than a value. make the polling retries so that at the next retry counter it should pass.
>  
> {quote}int count = 0;
> new Polling(() -> {  count++;   Assert.assertTrue(count == 2);  return true;         }
> ).poll(2000, 500);
> {quote}
> Observation: it exist the poll directly as the assert fail already.
> Expected: It should have polled until the check pass here.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)