Just an FYI for anyone interested in this topic: Following review comments, the latest patch set of https://git.opendaylight.org/gerrit/#/c/48077/ is now significantly reworked from the original design from 3 days ago. More +1/-1 welcome... BTW: That new ChainableDataTreeChangeListener API idea could, later, perhaps even be moved from Genius to controller/mdsal?
On Mon, Nov 7, 2016 at 6:48 PM, Michael Vorburger <vorbur...@redhat.com> wrote: > Back to a thread from 3 months ago, read up previous exchange to jump in: > > On Fri, Aug 12, 2016 at 1:50 PM, Michael Vorburger <vorbur...@redhat.com> > wrote: > >> Tomas, tx for your prompt reply. I hadn't seen Mockito's [1] [2] >> timeout() before, thanks for pointing it out. Similar to e.g. awaitility >> [3], but built in to Mockito - nice. >> >> FYI This particular test is an "end-to-end" test, so the listeners aren't >> mocked but the real thing.. but the general approach you outline may still >> work. I'd probably have to wrap the real ones somehow.. perhaps even just >> Mock and use Mockito CallsRealMethods (or via my >> CallsRealOrExceptionAnswer.java >> <https://git.opendaylight.org/gerrit/#/c/42529/8/common/testutils/src/main/java/org/opendaylight/yangtools/testutils/mockito/CallsRealOrExceptionAnswer.java> >> from [5], but not needed here) may help - I need to see if it's possible to >> combine. I'd need to hook into the instantiation of the real listeners, >> which ties in with some thinking I'm doing re. in-bundle DI (full >> disclosure & tangent: I'm not a big fan of blueprints for that, in-bundle; >> I see blueprints as one possible answer to the problem of wiring between >> bundles; with DS another choice). >> >> All: Before jumping into pursuing this, >> > > I now have jumped into this, and would like to propose > https://git.opendaylight.org/gerrit/#/c/48077/ - how do you guys like the > proposed idea? > > https://git.opendaylight.org/gerrit/#/c/48078/ has a usage example which > illustrates how by introducing this I can avoid silly Thread.sleep() - and > thus make those component tests run a bit faster. > > BTW: Testing async stuff is just a PITA in general; > https://git.opendaylight.org/gerrit/#/c/48061/ has another thingie like > that; that one isn't directly related to this thread re. listeners, just > mentioning it as a related proposed gerrit in the same area. > > >> could I just ask once again if there isn't another way to tackle this >> problem from "the other side" - instead of waiting on the Listener(s!), >> could one not ask a DataBroker "have all of your listeners already >> processed all of your pending puts" ? From the POV of writing a functional >> end2end test, this would seem easier to me. No way? >> > > FTR: There never was any reply to this question, and from the little > investigation I did, I couldn't figure out how to tackle this on that side > - thus the approach proposed above. > > >> >> [1] http://site.mockito.org/mockito/docs/current/org/mockito/ >> Mockito.html#timeout(long) >> [2] https://github.com/mockito/mockito/blob/master/src/test/java >> /org/mockitousage/verification/VerificationWithTimeoutTest.java >> [3] https://github.com/awaitility/awaitility >> [4] https://git.opendaylight.org/gerrit/#/c/42529/ >> >> Tx, >> M. >> -- >> Michael Vorburger <vorbur...@redhat.com> | IRC: vorburger @freenode | ~ >> = http://vorburger.ch >> >> >> On Thu, Aug 11, 2016 at 6:05 PM, Tomas Cere -X (tcere - PANTHEON >> TECHNOLOGIES at Cisco) <tc...@cisco.com> wrote: >> >>> Did you try mocking the listeners? With mockito you can verify if/how >>> many times a method has been called with a timeout and also >>> >>> use argument captors to check the value was as expected. I recently did >>> something similar in [1] >>> >>> >>> >>> [1]: https://github.com/opendaylight/mdsal/blob/28e0ef3b11e12112c >>> 0acc89ba07f59cc742f7417/dom/mdsal-dom-broker/src/test/java/ >>> org/opendaylight/mdsal/dom/broker/ShardedDOMDataTreeProdu >>> cerMultiShardTest.java#L192-L214 >>> >>> >>> >>> Tomas >>> >>> >>> >>> *From:* controller-dev-boun...@lists.opendaylight.org [mailto: >>> controller-dev-boun...@lists.opendaylight.org] *On Behalf Of *Michael >>> Vorburger >>> *Sent:* Thursday, August 11, 2016 17:47 >>> *To:* controller-dev; Kitt, Stephen; Alexis de Talhouët; Tom Pantelis; >>> Sam Hague; Robert Varga >>> *Subject:* [controller-dev] How to correctly wait for events to have >>> been processed in an AbstractDataBrokerTest? >>> >>> >>> >>> Ahoi controller-dev and others who may have an idea (please + anyone >>> else applicable), >>> >>> How do you write an AbstractDataBrokerTest and in it wait for a put on >>> the DataBroker to have processed by all of its registered >>> DataTreeChangeListener ? >>> >>> Background with concrete example: The (Abstract)AclServiceTest in >>> https://git.opendaylight.org/gerrit/#/c/42109/ (see [1]) puts two >>> entries into the DataBroker, the 2nd of which triggers a >>> DataTreeChangeListener which ultimately calls some service. The test >>> asserts that this service got called (slightly simplified, but that's the >>> gist of that test). >>> >>> I've inserted a Thread.sleep(500) after the DataBroker put and before >>> the assert, to give the DataTreeChangeListener a chance - I understand runs >>> asynchronously, right? >>> >>> This sleep makes that test work just fine (contrary to without any >>> sleep, when it fails, but just sometimes; that's always fun) - but I'm >>> wondering if there would be better way to write these kind of tests, >>> without sleep ... but not quite clear in my mind yet how. >>> >>> I've written tests like this before, using e.g. >>> https://github.com/awaitility/awaitility, which is just a nice utility >>> to poll say every 100ms for max. 2s for a certain condition to be true - >>> but what is that condition in this scenario - what API / helper would one >>> use to ask a DataBroker "have all of your listeners already processed all >>> of your pending puts" ? If this is impossible as is today, would this seem >>> like a fair enhancement request - would you consider adding something like >>> this, specifically to aid in writing tests? >>> >>> >>> [1] (Abstract)AclServiceTest is an AbstractDataBrokerTest, even if it >>> doesn't extend AbstractDataBrokerTest; ignore that, it's just because of >>> https://git.opendaylight.org/gerrit/#/c/43645/ >>> >>> Thanks a lot, >>> >>> M. >>> >>> -- >>> >>> Michael Vorburger <vorbur...@redhat.com> | IRC: vorburger @freenode | ~ >>> = http://vorburger.ch >>> >> >> > > > -- > > Tx, > M. > -- > Michael Vorburger <vorbur...@redhat.com> | IRC: vorburger @freenode | ~ = > http://vorburger.ch > -- Tx, M. -- Michael Vorburger <vorbur...@redhat.com> | IRC: vorburger @freenode | ~ = http://vorburger.ch
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
