Just had my latest piece on Kotlin’s lack of

package-private

published: https://levelup.gitconnected.com/kotlin-unit-testing-classes-without-leaking-public-api-871468695447 I’m sure you’re all aware of it, but I thought I’d share 🙂

There is a rather good discussion in the comments at https://henrikwarne.com/2014/02/09/unit-testing-private-methods/ that talks some about this topic.

I've found that classes being internal works out the best. You can provide instances of those classes to your public classes as either mocks or concrete instances depending your liking. Open class is a code smell to me since you are allowing for a class to be extended for the sake of tests. Making functions protected when they could be private is another smell IMO, if they shouldn't be extended then they shouldn't be extended.

how about using `@VisibleForTesting`Annotation?

I can see how it could be useful. Personally I've never had a need for that though. More or less following SOLID leads to fairly easy to test code.

sometimes when you need to aim that 70%+ coverage you probably need to do these kind of things. 😛

I've hit 70%+ coverage without it which is usually testing everything minus Views (but including viewmodels). If you find yourself having to test private functions more often than not it's a code smell.