https://kotlinlang.org logo
#kotest
Title
# kotest
d

dave08

03/23/2021, 7:30 AM
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
Although I think things are still pretty awkward... I had to do this to initialize WireMock with Robolectric:
Copy code
@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))
....
And make my own lazy wiremock listener...
since two classloaders try to load the same class it causes a
LinkageError
if I don't make it lazy...
I wonder if there's something that could ease using this extension a bit more naturally with everything else?
w

wasyl

03/23/2021, 8:10 AM
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
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
d

dave08

03/23/2021, 8:14 AM
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...
Btw, I think the
@Config
annotation is supported...
w

wasyl

03/23/2021, 8:20 AM
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
d

dave08

03/23/2021, 8:22 AM
Yeah, in that sense it might be limited I guess, but still useful in our use cases if not so clean...
👍 1
7 Views