Hi Bertrand, Yes, I think it's even simpler to implement, because I didn't work with OSGi events before. I just thought It's not a good way to tests that. Ok, then I will add Thread.sleep(300)(?) calls before checking that content was uninstalled. By the way, first time I tried to understand how I can extend your ContentBundleTestBase class and use with several bundles, but after I didn't find a nice solution for that, I did it in my way.
-Petr 2015-06-30 12:03 GMT+02:00 Bertrand Delacretaz <[email protected]>: > Hi Petr, > > On Tue, Jun 30, 2015 at 11:02 AM, Petr Shypila <[email protected]> > wrote: > > ...I think the best way to solve this problem is > > to subscribe for BundleEvent.UNINSTALLED event of these bundles.... > > That might not be sufficient, as I suppose the content loader acts > asynchronously, potentially after that event is emitted. > > To verify that you might add some sleep(...) calls in the content > loader, and see if that causes your tests to fail. > > Another strategy would be just to add some retry loops in your tests, > to wait for what you expect to happen (a property being overwritten > etc.), with a timeout - that might solve most of those cases. > > -Bertrand >
