> The design of AbstractConcurrentDataBrokerTest constructor is very misleading, as "single threaded executor" is in fact directExecutor().

The (protected) constructor which takes a boolean useMTDataTreeChangeListenerExecutor argument lets tests chose to use an Executors.newCachedThreadPool() intead of a newDirectExecutorService (via ConcurrentDataBrokerTestCustomizer).

> A replacement should really have two favors:
> don't care about DTCL delivery, run asynchronously

IMHO users doing integration tests in the future should not use AbstractConcurrentDataBrokerTest at all anymore, but the Guice Modules hopefully upcoming in MDSAL-418 ...

> postpone DTCLs and allow the test to deliver them as needed (all or one by one)

That would be cool.

PS: More of an FYI, but "component" integration tests which I was trying to promote 1-2 years ago have never really fully taken off; folks seem to prefer CSIT.

CachedThreadPool does not allow control over when messages are delivered, leading to Thread.sleep() in tests. The use of directExecutor is completely bad, as it makes people there are producer/consumer deadlocks due to the coupling introduced by that executor – and not realizing this, they code up workarounds and needlessly complicate their code.

Tying testing to a particular DI framework is not a good idea, I think, because Guice took quite a while to be usable with Java 11 – we do not want to get blocked again on such a think.

And as for usage – depends where you look. BGPCEP is full of component integration tests.

Having prototyped this a bit, I think we want to move away from 'AbstractTest' pattern to a 'TestKit' pattern, where the required functionality would be exposed as a utility class from which the users do not inherit.

This has couple of advantages:

1. not tying up class hierarchy – users may want to have freedom to structure their test classes more freely
2. allows per-testcase handling of DTCLs, as opposed to forcing all test cases in a class to use the same settings