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

The tragedy of 100% code coverage (2016)

labs.ig.com

Post reply on HN
Print view View original

161–170 of 346 posts

Re: The tragedy of 100% code coverage (2016)

#161

Post by mianos »

scottschulthess wrote: post #140
iamleppert wrote: post #114

The worse the developer, the more tests he'll write. Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poorly abstracted, weird code that is prone to breaking without an extensive "test suite" to hold the madness together and god forbid raise an alert when some unexpected file over here breaks a function over there. Tests will be poorly written, pointless, and give…

So the worst of us developers out there write tons of tests? We wish. Who cares if it's 80% or 100%, i'd rather inherit a codebase with lots of test coverage than without.

I wish to inherit code that is clear, concise and works over any tests thanks. Each to his own.

Re: The tragedy of 100% code coverage (2016)

#162

Post by circlefavshape »

/me raises hand on the pro-testing side

I've been programming for a living since 1996, and only recently started to do TDD in the normal sense of writing unit tests before writing code. I've found to it to be an enormous help with keeping my code simple - the tests or the mocking getting difficult is a great indicator that my code can be simplified or generalised somehow

I argued for functional instead of unit testing for years, but it was only when a team-mate convinced me to try unit testing (and writing the tests FIRST) that the scales fell from my eyes. Unit testing isn't really testing, it's a tool for writing better code.

BTW from an operational perspective I've found it's most effective to insist on 100% coverage, but to use annotations to tell the code coverage tool to ignore stuff the team has actively decided not to test - much easier to pick up the uncovered stuff in code review and come to an agreement on whether it's ok to ignore

Re: The tragedy of 100% code coverage (2016)

#163

Post by mcv »

thinkloop wrote: post #49
cbanek wrote: post #36

Earlier quoted context omitted.

Indeed. It's almost as if testing should be built into the language itself. (I'm always a big fan of including self-test code in projects)

> testing should be built into the language itself I wonder what that would look like...

Didn't Smalltalk do something like that? I thought it had TDD built into its standard IDE.

Re: The tragedy of 100% code coverage (2016)

#165

Post by baq »

mianos wrote: post #161
scottschulthess wrote: post #140

Earlier quoted context omitted.

So the worst of us developers out there write tons of tests? We wish. Who cares if it's 80% or 100%, i'd rather inherit a codebase with lots of test coverage than without.

I wish to inherit code that is clear, concise and works over any tests thanks. Each to his own.

Unit tests are a tool to get the codebase to that point... When used properly.

Re: The tragedy of 100% code coverage (2016)

#166

Post by koevet »

iamleppert wrote: post #114

The worse the developer, the more tests he'll write. Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poorly abstracted, weird code that is prone to breaking without an extensive "test suite" to hold the madness together and god forbid raise an alert when some unexpected file over here breaks a function over there. Tests will be poorly written, pointless, and give…

> The worse the developer, the more tests he'll write.

This is not only wrong, but also dangerous.

I agree with the second part of your comment (about being pedantic about the number of unit tests), but a good and comprehensive test suite is fundamental for large projects, especially projects with many moving parts and a large turn-over of people (basically any big enterprise).

Re: The tragedy of 100% code coverage (2016)

#167

Post by scalatohaskell »

adamlett wrote: post #153
scalatohaskell wrote: post #118

Earlier quoted context omitted.

This hits home with me. Incompetent developers need dogmatisms (100% unit coverage!!!! etc)

No, inexperienced developers need dogmatisms. Subtle difference perhaps, but it's worth remembering that every competent developer started out being inexperienced, and that it's nothing to be ashamed of.

You are correct. I was once inexperienced and was very dogmatic.

Re: The tragedy of 100% code coverage (2016)

#168

Post by scottschulthess »

mianos wrote: post #161
scottschulthess wrote: post #140

Earlier quoted context omitted.

So the worst of us developers out there write tons of tests? We wish. Who cares if it's 80% or 100%, i'd rather inherit a codebase with lots of test coverage than without.

I wish to inherit code that is clear, concise and works over any tests thanks. Each to his own.

So you're saying test coverage is a negative? It's not an either or.

Re: The tragedy of 100% code coverage (2016)

#169

Post by nuclx »

tjalfi wrote: post #48
fowl2 wrote: post #43

Earlier quoted context omitted.

Which why I really love things like MSR's PEX[1]. "Pex uses a constraint solver to produce new test inputs which exercise different program behavior. " So this is not lines, but I guess.. branches and numerical limits. Either way it's cool and I wish it was integrated somewhere. They've got a online demo thing http://www.pexforfun.com/ [1] https://www.microsoft.com/en-us/research/publication/pex-whi...

IntelliTest[0] is the productized version of PEX. The first release was in Visual Studio 2015 Enterprise edition. [0] https://blogs.msdn.microsoft.com/visualstudio/2015/09/30/int...

Still a pity it's only included in Enterprise edition. We need a strong foundation of accessible tools for automated test input generation improving on the current state of the art fuzzers. See e.g. danluu's vision of "Combining AFL and QuickCheck for directed fuzzing" [https://danluu.com/testing/].

Re: The tragedy of 100% code coverage (2016)

#170

Post by jacques_chester »

dublinclontarf wrote: post #124
iamleppert wrote: post #114

The worse the developer, the more tests he'll write. Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poorly abstracted, weird code that is prone to breaking without an extensive "test suite" to hold the madness together and god forbid raise an alert when some unexpected file over here breaks a function over there. Tests will be poorly written, pointless, and give…

I inherited a code base with LOTS of test coverage. Made one small change and everything broke. Looked into the tests, oh the humanity!!! Dropped the test suite entirely, haven't had any issues since. We have VERY good logging and notifications though so anything goes wrong we know all about it.

> Dropped the test suite entirely, haven't had any issues since.

That you know about.

That bad test suites exist is unarguable.

Bad production code exists too, but we don't give up on writing production code.

Post reply on HN