Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This Code Is CRAP (2011)

testing.googleblog.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: This Code Is CRAP (2011)

#51

Post by kelnos »

Anonyneko wrote: post #7

>Note: This post is rated PG-13 for use of a mild expletive. If you are likely to be offended by the repeated use a word commonly heard in elementary school playgrounds, please don’t read any further. Mild as this ironic passive aggressiveness is, can't imagine something like this in modern sterile corporate messaging.

Man, when I was a kid in the 80s, my parents considered "crap" to be a bad word, and my sister and I would get in trouble for using it.

I'm sure that's still the case for some kids/parents today, but I can't imagine that being remotely common.

Re: This Code Is CRAP (2011)

#52

Post by kelnos »

datadrivenangel wrote: post #45
fallat wrote: post #8

> CRAP1(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) and > Here’s why we think that CRAP1 is a good anti-pattern to detect. Writing automated tests (e.g., using JUnit) for complex and convoluted code is particularly challenging, so crappy code usually comes with few, if any, automated tests. This is so wrong. The formula uses code coverage as a fundamental metric, when in reality, a lot of people write code "correct…

If the code is simple, the tests aren't much extra work. High test coverage doesn't mean your code is good, but it at least reduces the rate at which you accidentally break stuff.

> If the code is simple, the tests aren't much extra work.

Disagree. Even if it isn't much work to write (which is debatable), it still carries costs: CI takes longer to run, and the tests have to be carried and maintained (and possibly updated if the code itself changes).

> High test coverage doesn't mean your code is good, but it at least reduces the rate at which you accidentally break stuff.

Sure, for the most part. But that doesn't mean "more test code" is always a good thing. Tests aren't free, even for simple code.

Re: This Code Is CRAP (2011)

#53

Post by bunderbunder »

agentultra wrote: post #49
bunderbunder wrote: post #34

Earlier quoted context omitted.

Anecdotally, I’ve found that codebases that enforce code coverage metrics often have worse behavior coverage than ones that don’t. It’s a classic example of Goodhart’s Law in action. Code coverage metrics only measure what percentage of code the test suite causes to run. But it’s very, very easy to write tests that run code without actually confirming that it produces correct output for all possible inputs. And it’s…

Djikstra seemed like he was mostly against testing. But only because he was for proofs. A unit test is a single example. The real way to demonstrate the absence of errors is to prove they aren’t there (vis a vis axioms and assumptions). But most developers don’t have the mathematical sophistication nor the time. It’s not that unit testing is useless. Just good to know what their limitations are and to plan your testi…

You also have the problem of potentially having to re-verify everything by hand for every little change. Maybe fine for the kinds of projects Dijkstra was working on, but less practical in a business setting.

Tools like QuickCheck and Hypothesis are an interesting middle ground, though. I strongly prefer them over standard-issue unit testing for verifying algorithm implementations.

Re: This Code Is CRAP (2011)

#54

Post by agentultra »

bunderbunder wrote: post #53
agentultra wrote: post #49

Earlier quoted context omitted.

Djikstra seemed like he was mostly against testing. But only because he was for proofs. A unit test is a single example. The real way to demonstrate the absence of errors is to prove they aren’t there (vis a vis axioms and assumptions). But most developers don’t have the mathematical sophistication nor the time. It’s not that unit testing is useless. Just good to know what their limitations are and to plan your testi…

You also have the problem of potentially having to re-verify everything by hand for every little change. Maybe fine for the kinds of projects Dijkstra was working on, but less practical in a business setting. Tools like QuickCheck and Hypothesis are an interesting middle ground, though. I strongly prefer them over standard-issue unit testing for verifying algorithm implementations.

Hundred percent. All about trade-offs.

Although proof techniques such as proof repair have come a long way, it’s still impractical for a lot of scenarios.

TLA+ is great for systems design and such. Quick check style tests are awesome and a very low bar to clear from unit tests.

Re: This Code Is CRAP (2011)

#55

Post by bunderbunder »

agentultra wrote: post #54
bunderbunder wrote: post #53

Earlier quoted context omitted.

You also have the problem of potentially having to re-verify everything by hand for every little change. Maybe fine for the kinds of projects Dijkstra was working on, but less practical in a business setting. Tools like QuickCheck and Hypothesis are an interesting middle ground, though. I strongly prefer them over standard-issue unit testing for verifying algorithm implementations.

Hundred percent. All about trade-offs. Although proof techniques such as proof repair have come a long way, it’s still impractical for a lot of scenarios. TLA+ is great for systems design and such. Quick check style tests are awesome and a very low bar to clear from unit tests.

Yeah. And TLA+ can confirm that the design is sound, but it can’t confirm that the implementation conforms to the design. QuickCheck style tests can’t solve that problem, but perhaps they can mitigate it.
Post reply on HN