7 ms·
I feel like the arguments would've been better applied to kotlin (especially with IntelliJ). Java has two big problems: Null and boilerplate code (getters, sett
by RamblingCTO 6y ago
I feel like the arguments would've been better applied to kotlin (especially with IntelliJ). Java has two big problems: Null and boilerplate code (getters, setters etc.) which messes with code coverage (and no, lombok is no appropriate solution to this). Kotlin is pretty null safe and has very little things which we cannot properly test. The language is easy to learn and fun to write. It feels sleek, modern and you need to write less code than compared to java. You still get the whole ecosystem and can even migrate file-by-file. We actually still have a mixed codebase with 30% java and 70% kotlin (rough estimate) and it works wonderfully.
- kaba0 6y agoHaving 100% code coverage just because is not meaningful in itself, so I don’t see your point. Having 100% is just as not enough because you can arrive at a line of code from exponentially many states. Mutation testing is a good way to show whether the tests are actually worth anything.
- RamblingCTO 6y agoYou misunderstood me. You would need to add tests for getters and setters to guarantee that there's no typo in there (I've seen quite some bugs due to this) but it feels like a waste of time. That's why I'm happy that that's not necessary with kotlin. Code coverage is just a control tool.