Given the balance of simplicity, convenience, and the need for some level of encapsulation, here's a tailored approach:
Public by Default:
For the majority of your test classes, especially those in commonTest and shared utilities, use public visibility. This approach maximises reusability and simplifies the development process.
Selective Use of internal:
For tests that are strictly tied to platform-specific implementations and where you want to enforce clear boundaries, consider using internal. This would typically be in androidTest or desktopTest source sets for tests dealing with platform-specific APIs or UI components.
Conclusion
If I were in your position, I would lean towards keeping test classes public by default for the sake of simplicity and reusability. However, I would selectively use internal for platform-specific tests where encapsulation and clear module boundaries are particularly beneficial. This balanced approach allows for the best of both worlds: simplicity and accessibility for common tests, with encapsulation where it truly matters.
Recommendation
Given the balance of simplicity, convenience, and the need for some level of encapsulation, here's a tailored approach:
Public by Default:
commonTestand shared utilities, use public visibility. This approach maximises reusability and simplifies the development process.Selective Use of
internal:internal. This would typically be inandroidTestordesktopTestsource sets for tests dealing with platform-specific APIs or UI components.Conclusion
If I were in your position, I would lean towards keeping test classes public by default for the sake of simplicity and reusability. However, I would selectively use
internalfor platform-specific tests where encapsulation and clear module boundaries are particularly beneficial. This balanced approach allows for the best of both worlds: simplicity and accessibility for common tests, with encapsulation where it truly matters.