Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Part of maintainability is readability and ease of debugging, and I agree that Go shines here. But another part is the ease of refactoring and rewriting. My experience is that Go codebases which aren't fundamentally doing very much nevertheless become ossified through sheer volume. This is especially the case when you have layered packages (MVC, etc) and consequently a lot of mocks. Most conceivable changes implicate dozens to hundreds of mock expectation lines, and thus become more trouble than they're worth. This is largely because fully explicit control flow needs to be fully explicitly unit tested every single time. Those tests weigh a lot.


> Most conceivable changes implicate dozens to hundreds of mock expectation lines, and thus become more trouble than they're worth.

I've experienced the same thing in java, and similarly with testing different conditionals/exception cases in java

Usually most of the mock annoyingness I've personally dealt with is from repetitive, unrefactored test coverage




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: