Restore discovery tests

[Nadahar]

This should restore all tests that were either disabled or "weakened" in #19230 and #19473.

I've used the SameThreadExecutorService made available in openhab/openhab-core#5072 and openhab/openhab-core#5100, originally created by @david-pace, to remove the "delay" in discovery registration that was introduced by openhab/openhab-core#5032.

[Nadahar]

This failed on two bindings that I didn't touch, Network and Matter...

@lsiepel Can you restart the build? (I'm asking you because I saw you just post on the forum)

[Nadahar]

@david-pace I took the liberty of removing NullScheduledFuture and SameThreadExecutorService from the boschshc binding and use SameThreadExecutorService from Core instead. If that's not OK, please let me know and I'll revert it.

[Nadahar]

I found a flaky test in the network binding, so I addressed that (despite it not really being related to this PR). I'm just hoping that the Matter binding won't fail this time.

edit: I used SameThreadExecutorService from openhab/openhab-core#5072 to fix the Network binding as well, the same "tool" I've used to restore the tests in this PR. I think it has promise to address many flaky tests in general.

[Nadahar]

I just love getting a spotless failure because spotless (which is based on the Eclipse formatter) doesn't agree with the order of imports that Eclipse made automatically after 38 minutes of building 😠

[lsiepel]

I just love getting a spotless failure because spotless (which is based on the Eclipse formatter) doesn't agree with the order of imports that Eclipse made automatically after 38 minutes of building 😠

You can probably use a pre-build hook to run spotless:apply

[Nadahar]

You can probably use a pre-build hook to run spotless:apply

I'm not sure how to do that, but this isn't really a big problem - just very annoying because it takes so long to fail. Normally, when I work on a single binding, I always run spotless:apply before pushing. But, here, when doing a little bit here and a little bit there, and when I think I've only made minor changes that shouldn't "bother" spotless, I didn't do it - and was bitten (twice).

Edit: I'm hesitant to run spotless:apply on "unnecessary files", because there is some issue where it modifies files without changing anything (that I can find). This can make me get a huge list of "changed" files, where I have to revert all that aren't really changed.

[lsiepel]

I had it setup for a while to perform the spotless apply on a pre-commit hook that git provides. I know the frustration.

[Nadahar]

I had it setup for a while to perform the spotless apply on a pre-commit hook that git provides. I know the frustration.

Ah, you mean a Git hook. That's "too intrusive" for me, I don't like having spotless interfere with temporary commits, during rebasing etc. Resolving conflicts isn't that fun, so I only run it "when I'm done".

[Nadahar]

Getting rid of the issue where it modifies files without modifying them would help a lot though. It doesn't always do it, but when it does, it can modify hundreds of files, and then I have to figure out which one or two were actually changed, and revert the rest 😒

[Nadahar]

Finally, success 🥳

[lsiepel]

Tahnk you for chasing these timing issues and imp[rove these test to be stable.

LGTM

[david-pace]

Thanks for restoring the tests, @Nadahar 👍

[lsiepel]

@Nadahar the satel test is failing CI. Any thoughts on this?

[Nadahar]

@Nadahar the satel test is failing CI. Any thoughts on this?

I'm pretty sure the reason is that I don't understand @InjectMocks, so that it doesn't work like I thought it did. Basically, I don't think the SameThreadExecutorService is actually used, or the flakiness shouldn't be possible:

org.opentest4j.AssertionFailedError: expected: <24> but was: <17>

It did pass when the tests were run for this PR, which means that the number of results must vary, which means that it must be another thread at play here.

Any hints for how to make sure that @InjectMocks actually uses the executor I want it to would be appreciated.

[lsiepel]

If i remember correctly, @david-pace had similar problecmts with mock annotations. Maybe he knows