5 ms·

In other words "be smart, don't be stupid". Do you really need to write a test for that single expression setter? But then again, it may be easier to just set

by vesak 10y ago

In other words "be smart, don't be stupid". Do you really need to write a test for that single expression setter? But then again, it may be easier to just set a single round goal like 100% for test coverage. Writing that test for the single expression setter won't cost you a lot.

brightball 10y ago
I can't remember the talk but one of the guys who really pushed agility in programming has even said that 100% test coverage should not be a goal. The talk he gave was more about testing the things that need testing and was a bit flabbergasted at the people who ran with the 100% coverage concept as part of it.
- wolfgang42 10y ago
  I've always viewed the code coverage metric as "what percentage of things that are supposed to be tested are actually tested?" From this perspective, anything less than 100% is a serious failing--it means that you've forgotten to test something you think is supposed to be tested. Now, the correct response may well be to decide that that particular bit of code shouldn't be tested after all. Sometimes this means adding a /coverage skip if: an outgrabed momerath is hard to reproduce on demand/ for a particularly tricky corner case, but more often it means that you haven't correctly separated your concerns and that particular piece of code actually belongs in a file that's not touched by the test suite.
repomies691 10y ago
> Writing that test for the single expression setter won't cost you a lot. Yeah, usually it won't cost anything to the guy who writes the test, but he is actually paid. What it costs to the business/customer/etc and whether the value added is worth of the cost is totally different matter. I think there is clear incentive for writing unnecessary tests for certain developers - it is non-risky general work, where it is is difficult to fuck up anyway. If you are able to sell test-writing hours, what's the downside?
- vesak 10y ago
  Difficult to even imagine a project that could fail business-wise because some developer wrote too many easy unit tests. Do you know of such cases?
  - repomies691 10y ago
    I know cases where too much focus on tests might be reason for a startup failure. Eg. instead of trying to find the product-market fit, resources are spent building tests, and then funding runs out. Of course it is very difficult to argue whether test writing was the issue or something else, and people have different incentives related to that.
  - bryanrasmussen 10y ago
    probably won't fail business-wise, but will cost incrementally more for each test business-wise.
    - vesak 10y ago
      Significantly?
      - repomies69 10y ago
        Depends on the business case. I don't think this answer can be generalized either way. You can lose a business because of the heavy costs which add little value, however it is not easily arguable that a specific cost was the deal-breaker.
- couchand 10y ago
  Boy it would be great if writing code that added features could also be that safe and difficult to screw up.
tommorris 10y ago
When a junior dev tries to refactor said class and accidentally screws around with the behaviour of the setter function, having the tests blow up is handy.
alkonaut 10y ago
> Do you really need to write a test for that single expression setter? I doubt anyone does that. Having weird requirements like "all public methods should have at least one test" is insane. For many code bases that would be an order of magnitude more tests than a requirement of "100% test coverage"

by vesak 10y ago

brightball 10y ago

I can't remember the talk but one of the guys who really pushed agility in programming has even said that 100% test coverage should not be a goal. The talk he gave was more about testing the things that need testing and was a bit flabbergasted at the people who ran with the 100% coverage concept as part of it.

wolfgang42 10y ago
I've always viewed the code coverage metric as "what percentage of things that are supposed to be tested are actually tested?" From this perspective, anything less than 100% is a serious failing--it means that you've forgotten to test something you think is supposed to be tested. Now, the correct response may well be to decide that that particular bit of code shouldn't be tested after all. Sometimes this means adding a /coverage skip if: an outgrabed momerath is hard to reproduce on demand/ for a particularly tricky corner case, but more often it means that you haven't correctly separated your concerns and that particular piece of code actually belongs in a file that's not touched by the test suite.

repomies691 10y ago

> Writing that test for the single expression setter won't cost you a lot. Yeah, usually it won't cost anything to the guy who writes the test, but he is actually paid. What it costs to the business/customer/etc and whether the value added is worth of the cost is totally different matter. I think there is clear incentive for writing unnecessary tests for certain developers - it is non-risky general work, where it is is difficult to fuck up anyway. If you are able to sell test-writing hours, what's the downside?

vesak 10y ago
Difficult to even imagine a project that could fail business-wise because some developer wrote too many easy unit tests. Do you know of such cases?
- repomies691 10y ago
  I know cases where too much focus on tests might be reason for a startup failure. Eg. instead of trying to find the product-market fit, resources are spent building tests, and then funding runs out. Of course it is very difficult to argue whether test writing was the issue or something else, and people have different incentives related to that.
- bryanrasmussen 10y ago
  probably won't fail business-wise, but will cost incrementally more for each test business-wise.
  - vesak 10y ago
    Significantly?
    - repomies69 10y ago
      Depends on the business case. I don't think this answer can be generalized either way. You can lose a business because of the heavy costs which add little value, however it is not easily arguable that a specific cost was the deal-breaker.
couchand 10y ago
Boy it would be great if writing code that added features could also be that safe and difficult to screw up.

tommorris 10y ago

When a junior dev tries to refactor said class and accidentally screws around with the behaviour of the setter function, having the tests blow up is handy.

alkonaut 10y ago

> Do you really need to write a test for that single expression setter? I doubt anyone does that. Having weird requirements like "all public methods should have at least one test" is insane. For many code bases that would be an order of magnitude more tests than a requirement of "100% test coverage"