171–180 of 329 posts
I think there's this myth that TDD is one of the best ways to write software and if you admit you don't do it, you'll be seen as a cowboy and will look stupid. I think the truth is TDD has its pros and cons, and the weight of each pro and con is highly dependent on the project you're doing. - The uncomfortable truth for some is that not doing any testing at all can be a perfectly fine trade off and there's plenty of…
No. And also 'do you write a test for everything?'. Also No. Tried it, ended up with too many tests. Quelle surprise. There is a time/money/cognitive cost to writing all those tests, they bring some benefit but usually not enough to cover the costs. I'm also going off the 'architect everything into a million pieces to make unit testing "easier"' approach. I heard someone saying that if you write a test and it never f…
Do you consider coverage an effective metric? I've got some code that has a test suite which is effectively a bunch of low level driver checks, plus a bunch of common example snippets and checks for eg empty inputs etc. Coverage gives an idea of how many lines of code have been run, but obviously no guarantees of correctness for those specific lines (eg you can't detect a double negative). It's worked well for me so…
That said, I've found issues specifically after targetting blocks for testing, which were highlighted by incomplete coverage. It's crucial to always remember that coverage is predicated on have good tests. At the very least every test must test something. Sounds obvious, however it's possible to get 100% coverage with a single test, test nothing, and still miss issues.
Earlier quoted context omitted.
Suddenly I feel very lonely for the fact I do actually clean the kitchen during and right after cooking...
And I feel glad I still have my mom and am calling her regularly. Call your moms!
(I feel bad I don't phone more often)
Earlier quoted context omitted.
I believed it until your password remark. That's a bad, bad practice.
Enlighten me, why?
I think the above commenter is thinking about the requirement a user to change a password on a timed basis. There's been a good bit of research done in this area, and the consensus is that it just causes most people to stick a number at the end of their password anyway, making the policy completely worthless at best, but it often leads to people writing their passwords down.
Yeah. I also floss every day, clean up the kitchen as I cook, keep off-site backups of my personal data, call my mother regularly to thank her for raising me, read the terms and conditions to online services, keep an up-to-date to-do list, and change all my passwords once a month.
1. As a security system for your code
2. As a tool for thought, prompting the application of inverse problem solving
Both of these have costs and benefits. If you consider the metaphor of the security system, you could secure your house at every entry point, purchase motion sensors, heat detectors, a body guard, etc. etc. If you're Jeff Bezos maybe all of that makes sense. If you're a normal person it's prohibitively expensive and probably provides value that is nowhere near proportional to its cost. You also have to be aware that there is no such thing as perfect security. You could buy the most expensive system on earth and something still might get through. So security is about risk, probability, tradeoffs, and intelligent investment. It's never going to be perfect.
Inverse thinking is an incredibly powerful tool for problem solving, but it's not always necessary or useful. I do think if you haven't practiced something like TDD, it's great to start by over applying it so that you can get in the habit, see the benefit, and then slowly scale back as you better understand the method's pros and cons.
At the end of the day, any practice or discipline should be tied to values. If you don't know WHY you're doing it and what you're getting out of it, then why are you doing it at all? Maybe as an exploratory exercise, but beyond the learning phase you should only do it if you understand why you're doing it.
No. Tests are like any other code. They incur technical debt and bugs at the same rate as other code. They also introduce friction to the development process. As your test suite grows, your dev process often begins to slow down unless you apply additional work to grease the wheels, which is yet another often unmeasured cost of testing in this fashion. So, in short, I view tests as a super useful, but over-applied too…
No. And also 'do you write a test for everything?'. Also No. Tried it, ended up with too many tests. Quelle surprise. There is a time/money/cognitive cost to writing all those tests, they bring some benefit but usually not enough to cover the costs. I'm also going off the 'architect everything into a million pieces to make unit testing "easier"' approach. I heard someone saying that if you write a test and it never f…