11–20 of 154 posts
"Trying to improve software quality by increasing the amount of testing is like try[ing] to lose weight by weighing yourself more often."
From someone who has lost over 15kg in the past in few months, one of the things that helped most was starting weighing myself as I didn't do that previously. It kept reminding me that I wasn't still there and gave me more motivation
> I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development And he's lost me in his first sentence. Unit testing, good unit testing at least, is not just about developing as it is about preventing regressions. A unit test that runs on every build ensure that something is true and that it stays true forever.
I love the first quote for how (ironically) true it is: "Trying to improve software quality by increasing the amount of testing is like try[ing] to lose weight by weighing yourself more often." From someone who has lost over 15kg in the past in few months, one of the things that helped most was starting weighing myself as I didn't do that previously. It kept reminding me that I wasn't still there and gave me more mot…
"Frequent Self-Weighing and Visual Feedback for Weight Loss in Overweight Adults"
"The major finding of this study is that the use of frequent weighing accompanied by visual feedback of weight, without a prescribed diet or exercise plan, was effective in producing a small but sustainable weight loss in overweight males."
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv...
And yes, it may be stupid to test before a design emerges - but only if you start with a very fine-grained test. Usually when I'm coding from scratch I write a very, very, VERY coarse-grained test that "tests something", and when I reach the point of passing it (which may involved creating and designing multiple classes) I probably have a working design and I may begin creating other, smaller unit tests for individual components. The initial test may disappear or become an integration or acceptance test.
By the way there's little content in the article. It's just a rant. And the article about not writing test cases at all is simply ridiculous - since an error can exist in a test, we shouldn't write test cases?!?
> I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development And he's lost me in his first sentence. Unit testing, good unit testing at least, is not just about developing as it is about preventing regressions. A unit test that runs on every build ensure that something is true and that it stays true forever.
It depends what you're developing, and who you're developing with. If you're developing something which must work 100% every time or else someone will die, then unit tests are a must. If you're developing with people who break the build all the time, then unit tests are useful. Unit tests that aren't 100% up to date with the code are worse than no unit tests.
A bit of a tautology... broken code is broken. Unmaintained code, even unit tests, should be deleted.
It also assumes a bug free app with 100% code coverage is the objective, regardless of the cost it takes to write all that test code. An app that has a few bugs but takes half the resources to develop can make better business sense.
A while back I described the benefits I think unit tests give you: 1. Well-tested parts 2. Decoupled design 3. Rapid feedback 4. Local context to test in. At the same time, there are many cases where they don't help much. More here: http://henrikwarne.com/2014/09/04/a-response-to-why-most-uni...
> I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development And he's lost me in his first sentence. Unit testing, good unit testing at least, is not just about developing as it is about preventing regressions. A unit test that runs on every build ensure that something is true and that it stays true forever.
It depends what you're developing, and who you're developing with. If you're developing something which must work 100% every time or else someone will die, then unit tests are a must. If you're developing with people who break the build all the time, then unit tests are useful. Unit tests that aren't 100% up to date with the code are worse than no unit tests.
If any piece doesn't succeed, the command stops. No push without unit tests passing.