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, 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? [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/ > 28e0ef3b11e12112c0acc89ba07f59cc742f7417/dom/mdsal-dom- > broker/src/test/java/org/opendaylight/mdsal/dom/broker/ > ShardedDOMDataTreeProducerMultiShardTest.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 >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
