Oh... it seems like the Kotest robolectric extension doesn't initialize the robolectric classloader ...

# kotest

[dave08]

Oh... it seems like the Kotest robolectric extension doesn't initialize the robolectric classloader and environment when the class is created, so all val s at the class level use the original classloader... is this really the only way, or can this be fixed? It seems it's linked to this issue: https://github.com/android/android-test/issues/409

[dave08]

@LeoColman This commit https://github.com/kotest/kotest-extensions-robolectric/commit/d1c84cd7a469a899beef857aa8ab8aa51620fca8 saved the day unintentionally! Thanks!

[dave08]

Although I think things are still pretty awkward... I had to do this to initialize WireMock with Robolectric:

@RobolectricTest
@Config(manifest= Config.NONE)
class SyncAuthenticationTest : FreeSpec() {
	private var syncApi: Lazy<WireMockServer> = lazy { WireMockServer(
			WireMockConfiguration.options()
					.port(30111)
					.notifier(ConsoleNotifier(true))
	) }

	private lateinit var am: AccountManager

	init {
		beforeSpec {
			am = AccountManager.get(getApplicationContext())
		}

		listener(LazyWireMockListener(syncApi, ListenerMode.PER_SPEC))
....

[dave08]

And make my own lazy wiremock listener...

[dave08]

since two classloaders try to load the same class it causes a LinkageError if I don't make it lazy...

[dave08]

I wonder if there's something that could ease using this extension a bit more naturally with everything else?

[wasyl]

I think Robolectric support is fundamentally broken/based on hacky workarounds because JUnit5 doesn’t have API to specify per-test classloaders: https://github.com/junit-team/junit5/issues/201

[wasyl]

So if anything’s awkward or inconvenient there’s good chance this issue is the reason. I recall we gave up on Robolectric in Kotest when we realized configuration support is very limited

[dave08]

Yeah, but would that even help here? It's nice to have things like WireMock and AccountManager at the Spec/class scope for extracting test setup functions... having a classloader set at test time reverts to the state it was before that commit...

[dave08]

Btw, I think the @Config annotation is supported...

[wasyl]

ah sorry, I saw Robolectric support and just had flashbacks 😛
Last I remember @Config was supported just once for the entire class, but we wanted to have tests like forall with different locale in config, and we couldn’t do it, we tried reimplementing the robolectric support too. That’s why I’m suggesting that any classloader-related stuff will be awkward and unlikely to support all convenient use cases

[dave08]

Yeah, in that sense it might be limited I guess, but still useful in our use cases if not so clean...