Hacker News Reader

Comment by politelemon | Hacker News Reader

> With so many contradictory viewpoints, somebody has to be wrong! But who?

I think it's the opposite, there absolutely doesn't have to be a wrong. Assuming someone must be 'wrong' is not a healthy viewpoint to take.

What we're running into is a limitation in the languages and frameworks we use, and we are assuming that those languages frameworks are right, they are the only way things should be done. That limitation is then being expressed as the various viewpoints that author has listed.

I'm glad the author took the time to enumerate the various viewpoints and I'm sure there are more!

View on HN

I agree with your point about the dangers of right/wrong thinking, though when I wrote that line I was specifically thinking about people who say we should never test private methods vs people we say we should always test private methods, in which case they truly can't both be right. I've updated the post to make that clearer.

On your point about language limitations, I also wonder about this. I vaguely recall coming across a post that mentioned testing private methods just wasn't an option in various languages in the early days, and it's possible that were that not the case, we wouldn't have so many advocates of the never-test-directly viewpoint. That's not to say that the viewpoint is wrong though.

I think your blog post would be much stronger if you could give the "most compelling" examples you can find in favor of all the viewpoints, then explaining why any of them should trump the other. (I think they call that steel-manning?)

Of course this is hard/time-consuming, which I imagine is why you don't do it (and neither do most people arguing about issues like this), but it's the only way to honestly evaluate something. IMHO the answer you will come to is "it depends"... because of course it does. ;-) (For example, I'm pretty sure I could come up with examples of methods where e.g. making the function "pure" wouldn't really be a good trade-off, and I could also come up with examples where it would be.) But if you can arrive at a different answer, that would certainly be interesting.

I completely agree. The post became longer than I would have liked even without examples and didn't want to make it any longer with examples, though it would be a good basis for a follow-up post.

> What we're running into is a limitation in the languages and frameworks we use

Can you elaborate on this point more?

An example which comes to mind is how Racket handles tests: they're generally written in "sub-modules" of whatever they're testing, and hence they have access to "private" (AKA un-exported) definitions.

https://blog.racket-lang.org/2012/06/submodules.html

Framing discussions around "classes and methods" is a rather narrow-minded view, which ignores lots of potential solutions.

Reply on news.ycombinator.com