Hacker News Reader

Comment by codeulike | Hacker News Reader

No. And also 'do you write a test for everything?'. Also No.

Tried it, ended up with too many tests. Quelle surprise. There is a time/money/cognitive cost to writing all those tests, they bring some benefit but usually not enough to cover the costs.

I'm also going off the 'architect everything into a million pieces to make unit testing "easier"' approach.

I heard someone saying that if you write a test and it never fails, you've wasted your time. I think thats quite an interesting viewpoint.

Reminded of:

"Do programmers have any specific superstitions?"

"Yeah, but we call them best practices."

https://twitter.com/dbgrandi/status/508329463990734848

View on HN

Everyone's in the confessional booth here admitting dogmatic test-first-test-everything's not so hot in practice, which is nice, but how long until it becomes safe to answer with anything other than some variation of "love testing, it's always great, I love tests, more is better" when asked how you feel about testing in interviews?

I always answer this honestly in interviews and I've always had my interviewers say they feel the same way.

I think maybe it's a thing where you're not supposed to say it, but once you do, it frees the interviewer up to admit it as well and they're happy.

Oh of course you have to be enthusiastic about testing in interviews. Same as with agile!

Actually, for the interview for my current job (a pretty big corporation) they asked me about testing and I flatout said that I think testing has some benefit for some cases for , but I think the "100% CODE COVERAGE OMG TDD!!!" mentality is actually counter productive and makes code much harder to adapt.

I think they appreciated my honesty.

>No. And also 'do you write a test for everything?'. Also No.

Same here and for the same reasons plus stuff in the backlog that takes more priority; At least on Finance, gambling and telecom industries that I've worked on

Do you consider coverage an effective metric? I've got some code that has a test suite which is effectively a bunch of low level driver checks, plus a bunch of common example snippets and checks for eg empty inputs etc.

Coverage gives an idea of how many lines of code have been run, but obviously no guarantees of correctness for those specific lines (eg you can't detect a double negative).

It's worked well for me so far, since the important parts are (a) the hardware communication works and (b) users can process and output data in a way that is correct. No need to obsessively check the intermediate steps if the output is good.

I definitely think coverage is a worthy metric to track. It can provide meaningful information about the "doneness" of your tests. It shouldn't drive testing though, and especially, you shouldn't write your tests specifically "to get coverage". Yes, lots of people do this in environments where "getting 100% coverage" is mandatory.

That said, I've found issues specifically after targetting blocks for testing, which were highlighted by incomplete coverage. It's crucial to always remember that coverage is predicated on have good tests. At the very least every test must test something. Sounds obvious, however it's possible to get 100% coverage with a single test, test nothing, and still miss issues.

> which were highlighted by incomplete coverage

This is the single most important part of code coverage IMO: we don't care about what the tests cover, we care about what the humans never considered.

For this reason I'm a proponent of 100% coverage with a major caveat: Any code you explicitly decided not to test gets marked "no cover", so it doesn't count for or against the coverage score. This way branches that were accidentally missed really stand out, and we're not bogged down by having to test 100% of the code.

Great idea we'll just add

// Unit Testing begin not covered

// Unit Testing end not covered

To the start and end of every file (or however it's done in your suite). Then we can leave early, go to the bar, and have a nice pint ;)

I would agree that "coverage gives an idea of how many lines of code have been run, but obviously no guarantees of correctness for those specific lines"

Perhaps I should rephrase. If you're trying to effectively unit test a project, when do you decide you've tested enough? And are there any metrics which help support that?

Coverage for example is a weak signal that you've at least run some fraction of your codebase at test time.

I just write tests for the bits that I know I'm going to have lots of trouble with. You can tell, after a while

Reply on news.ycombinator.com