5 ms·

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 w

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 https://twitter.com/dbgrandi/status/508329463990734848

lelima 7y ago
>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
joshvm 7y ago
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.
- codeulike 7y ago
  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"
  - joshvm 7y ago
    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.
    - codeulike 7y ago
      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
- P_I_Staker 7y ago
  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.
  - Izkata 7y ago
    > 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.
    - P_I_Staker 7y ago
      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 ;)
shantly 7y ago
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?
- codeulike 7y ago
  Oh of course you have to be enthusiastic about testing in interviews. Same as with agile!
  - tombert 7y ago
    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.
- matttb 7y ago
  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.

lelima 7y ago

>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

joshvm 7y ago

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.

codeulike 7y ago
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"
- joshvm 7y ago
  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.
  - codeulike 7y ago
    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
P_I_Staker 7y ago
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.
- Izkata 7y ago
  > 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.
  - P_I_Staker 7y ago
    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 ;)

shantly 7y ago

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?

codeulike 7y ago
Oh of course you have to be enthusiastic about testing in interviews. Same as with agile!
- tombert 7y ago
  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.
matttb 7y ago
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.