7 ms·

I get the desire to ask that question, but it also feels like the main thing Copilot saves me is energy, which can’t be quantified in a very useful way. You’ll

I get the desire to ask that question, but it also feels like the main thing Copilot saves me is energy, which can’t be quantified in a very useful way. You’ll just have to take our words for it. Like, writing a really boring unit test might only take 60 seconds, but if Copilot can do it for me (even if I have to quickly scan it for correctness) that saves me… well something other than 60 seconds. It sure feels like a big deal.

haspok 4y ago
Why write that boring unit test at all? If it is not only boring, but also automatically generated, then what value does it add to the code? I would argue it actually _decreases_ the value, because you now have that much more code to maintain and understand. 90% of unit tests people write are garbage according to my experience.
- saimiam 4y ago
  This take is too reductionist. Every website ever has a boring unit test called “Is it up?” where you check if the site is still working after a deployment. Boring and repetitive but of infinite value if you can detect early that your deployment broke something. If a boring/boilerplate unit test like this can deliver value, other b/b unit tests are probably going to similar impacts and hence, saying they all “decrease” value is reductionist.
  - marcosdumay 4y ago
    > Every website ever has a boring unit test called “Is it up?” Yeah, and it should come almost automatically from the tooling. If you are writting this, you have a tooling problem.
    - lemmsjid 4y ago
      Why can't we come at it from both sides? Goal of library/language/framework designers: limit boilerplate and unnecessary code Goal of tool/IDE designers: make it easy to not spend time on boilerplate and unnecessary code. Both sides have built in limitations that will keep them from completely solving the problem. Terse, highly DRY code tends to also be highly abstracted and hard to read, with a lot of implicit behavior. On the other side, large amounts of generated code lead to tool lockin and cruft accumulation.
    - saimiam 4y ago
      No product starts with an elaborate ci/cd pipeline and automated test suite. Many evolve into needing such tooling after having had an incident or two when a deployment broke the site…and the response invariably is that “we should have written a suite of really basic tests which goes to the home page and checks if the hero image is visible.” If co-pilot’s autogenerated test cases can help prevent this head smacking, it will have proved that basic/boilerplate code was valuable. The site checker included in the tooling is just a more mature version of the boilerplate unit test co-pilot gives us. Btw, I have no skin in the game -never used co-pilot…just surprised that HN commenters can be so dismissive of wanting to get the basics right - like having some test coverage.

haspok 4y ago

Why write that boring unit test at all? If it is not only boring, but also automatically generated, then what value does it add to the code? I would argue it actually _decreases_ the value, because you now have that much more code to maintain and understand. 90% of unit tests people write are garbage according to my experience.

saimiam 4y ago
This take is too reductionist. Every website ever has a boring unit test called “Is it up?” where you check if the site is still working after a deployment. Boring and repetitive but of infinite value if you can detect early that your deployment broke something. If a boring/boilerplate unit test like this can deliver value, other b/b unit tests are probably going to similar impacts and hence, saying they all “decrease” value is reductionist.
- marcosdumay 4y ago
  > Every website ever has a boring unit test called “Is it up?” Yeah, and it should come almost automatically from the tooling. If you are writting this, you have a tooling problem.
  - lemmsjid 4y ago
    Why can't we come at it from both sides? Goal of library/language/framework designers: limit boilerplate and unnecessary code Goal of tool/IDE designers: make it easy to not spend time on boilerplate and unnecessary code. Both sides have built in limitations that will keep them from completely solving the problem. Terse, highly DRY code tends to also be highly abstracted and hard to read, with a lot of implicit behavior. On the other side, large amounts of generated code lead to tool lockin and cruft accumulation.
  - saimiam 4y ago
    No product starts with an elaborate ci/cd pipeline and automated test suite. Many evolve into needing such tooling after having had an incident or two when a deployment broke the site…and the response invariably is that “we should have written a suite of really basic tests which goes to the home page and checks if the hero image is visible.” If co-pilot’s autogenerated test cases can help prevent this head smacking, it will have proved that basic/boilerplate code was valuable. The site checker included in the tooling is just a more mature version of the boilerplate unit test co-pilot gives us. Btw, I have no skin in the game -never used co-pilot…just surprised that HN commenters can be so dismissive of wanting to get the basics right - like having some test coverage.