> 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 from construction", so coverage is not even applicable. Many times too, people only care the use cases they care about work perfectly.

There are also many other reasons code is not tested, not because it's complex, but because it's simple.

▲

datadrivenangel 2 hours ago | parent [-]

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.

	▲	kelnos an hour ago \| parent [-]
		> 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.