4 ms·
> Instead, it reduces that number to c' * N with c'<c and the difference being caused by your test coverage. That is unproven conjecture. It feels right, but
by gilbetron 8y ago
> Instead, it reduces that number to c' * N with c'<c and the difference being caused by your test coverage.
That is unproven conjecture. It feels right, but just because it is written as a formula doesn't automatically mean it is correct.
- peteradio 8y agoIt is an axiom. If your testing is such that this isn't true then you are doing testing wrong, in a self-evident sort of way.
- sidlls 8y agoThat's about as useful as observing that if your code is such that it doesn't produce the correct result then you've written the code wrong, in a self-evident sort of way.
- peteradio 8y ago> observing that if your code is such that it doesn't produce the correct result Hmm. Sounds like you are doing some sort of testing.
- joshuamorton 8y agoTo expand on the other commenter: If adding test code makes your code under test more bug-prone, something has gone horribly, terribly wrong.
- wildmanx 8y agoMaybe we have a disconnect in our definitions of "testing". How do you define the meaning of it, and could you illustrate how it could, on average over a code base, increase the number of bugs in the product code under test?
- Firadeoclus 8y agoAssuming the same time constraints, time spent writing tests competes with time spent writing product code. Ideally, tests save more time than would otherwise have been spent debugging and/or save time and money by catching bugs early. In bad cases you get no return on the time spent writing tests and simply end up with less product code (similar bugs/LOC, so fewer bugs and reduced features). In terrible cases you end up with rushed product code and more bugs/LOC.