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/ShardedDOMDataTreeP >> roducerMultiShardTest.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
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
