In a Kotlin multiplatform library, when generating...

# announcements

[Erik]

In a Kotlin multiplatform library, when generating test classes they become internal class FooTest. Why internal? Are they otherwise published or too accessible somehow?

[Erik]

An internal class FooTest in the commonTest module is accessible from other test modules, e.g. jvmTest. Not sure what internal does here

[Fleshgrinder]

I'd even make them private just to get them out of autocompletes. But, I don't know why they're internal and would also like to know.

[Erik]

Can they be private for the test framework? Not sure if kotlin-test can access private test classes and functions. E.g. JUnit cannot access private members

[Fleshgrinder]

JUnit 5 has no problem with private test classes.

[Erik]

Ah, yes, you're probably right. I have more experience with JUnit 4 so I was thinking about that

[Bruno Medeiros]

I think there are internal because it's better than public, tests won't be accessible outside of the modules anyway, and better than private because junit and other frameworks don't need to violate encapsulation to run your tests.

[Fleshgrinder]

Tests shouldn't encapsulate anything. 😉

[Bruno Medeiros]

I didn't say they should. I said test frameworks need to access your methods, and if Junit 5 "works fine" with private methods, it is doing so by using reflection and violating encapsulation.

[Fleshgrinder]

It's always using reflection because there's a lot of additional stuff that's applied via annotations and what not (e.g. @ExtendWith). It really makes no difference. 😉