The Java world has a standardised build layout and tools that automatically understand the difference between unit tests and main program code depending on where they are in the tree.
Which I personally consider a terrible idea (as the navigation in the parallel tree takes much time). Recognizing tests based on their name (or an annotation) would be IMHO much better. But I can live with the tree.
It'd be nice if the Kotlin toolchain used these conventions to compile the main code twice: once in which everything is public for the unit tests to use,
This can backfire if your code uses reflection on itself or a library does it. You'd actually test a slightly different code, which may sometimes lead to passing a test despite a bug. But such problems are most probably rare and Java testing/mocking frameworks suffer bigger problems of this kind.
For bonus points kotlinc could generate the two libraries in parallel, with a "last second" bytecode rewriting pass for the second jar making everything public.
I don’t know how easy this would be to implement, but it’d be a cool feature for possibly not much work and would solve a practical problem I’ve encountered many times in real Java codebases.
I guess making everything public and non-final should be pretty trivial and ligtning fast compared to compilation. Jmockit does this and also more complicated things on the fly http://jmockit.github.io/about.html.
A good IDE support directly allowing you to call private methods and extend private classes in tests would be damn cool. I guess, I love this idea.