Live data from Hacker News

Poll: Do you test your code?

news.ycombinator.com

161–170 of 351 posts

Re: Poll: Do you test your code?

#161
I think your definition of test is flawed. The majority of "testing" is just using your site to see if it is broken. You can write automation to pin point errors faster but it is not the way the majority of the world tests software.

Re: Poll: Do you test your code?

#162
I think TDD at times is overkill, but the core components of any app that others stand on MUST BE TESTED. The deeper your component is, the more critical tests are. Because if code a few levels deep breaks, it is much harder to fix/detect than something on the surface, which is usually immediately visible, immediately obvious, and low risk fixing.

Re: Poll: Do you test your code?

#163

Earlier quoted context omitted.

Well, there's `all` and there's virtually all. All is 100% branch and statement coverage, and is a big waste of time. When I saw my codebase has 'all' functionality tested, I mean we don't commit code without tests included too. I think that's a pretty reasonable definition.

100% branch and statement coverage doesn't begin to cover "all". Consider: double sin(double x) { return x; } Simply testing x = 0 gives you 100% branch and statement coverage, but I don't think you want to ship just yet =)

yep, you're absolutely right. You can get 100% testing coverage when you define it as "percentage of code executed when tests are run".

That said... that kind of coverage isn't quite as useless as it might seem. If your tests do execute every line, even in a completely contrived way, you will catch a lot if you change your code. You just tend to catch more of the "wrong number of arguments passed to a method" kind of error than "you are allowing the autopilot to try to land the plane 100 feet below the runway" kind of error ;)

Re: Poll: Do you test your code?

#166
post #146

Earlier quoted context omitted.

Do you always have the time/bandwidth to write these tests? Does an ER surgeon always have the time/bandwidth to scrub hands before surgery?

Does an ER surgeon always have the time/bandwidth to scrub hands before surgery? Does it potentially take the surgeon several days to scrub before an emergency surgery? Edited to add: I appreciate the analogy, but it's flawed. If someone comes to me and says "here, developer A is on holiday, and we have this bug that it causing massive disruption in the field," is it appropriate for me to say "well, I can do that, bu…

I see exactly where you're coming from, and I'm there all the time.

It just troubles me that people are so often willing (and eager!) to waste a lot of time doing half-assed manual testing when they claim not to have any time to write tests. Especially when the state of the art in test automation is better than it has ever been.

This has me thinking that the importance of test automation is related to the proposed frequency of changes. If someone wants a one-off change for something this very second I'll just change it. If someone wants me to inhabit a codebase for any length of time, I'll always set up tests for it. The problem is where you can't tell the difference between those two scenarios until it's too late.

Re: Poll: Do you test your code?

#167

I answered "a few critical things" ... but, for the most part, testing is tedious, frustrating, and a time-sink for me. I recently paid someone $100+ an hour for some remote TDD coaching. It's helping a bit but hasn't really change my attitude towards testing (yet). What bugs me: - Testing frameworks and "best practices" change way faster than language frameworks and I simply can't keep up. What rspec version do I us…

"- Most bugs/edge cases I encounter in our production apps are things I'd never think to write a test for ..."

This is why regression tests are my favorite type of test. The need for the test has been confirmed by real world usage and once you create the regression test to fail, fix the bug, and pass the test, you won't have to ever worry about users seeing that bug again :)

Re: Poll: Do you test your code?

#169

I answered "a few critical things" ... but, for the most part, testing is tedious, frustrating, and a time-sink for me. I recently paid someone $100+ an hour for some remote TDD coaching. It's helping a bit but hasn't really change my attitude towards testing (yet). What bugs me: - Testing frameworks and "best practices" change way faster than language frameworks and I simply can't keep up. What rspec version do I us…

but I don't ever see myself in the "test ALL the things" camp

Good for you. Extremists on all sides are usually wrong.

Shoot for "test MOST OF the things" or "test the MOST IMPORTANT things" or even "test just enough things so that you know if change Y totally breaks MOST IMPORTANT feature Z".

Re: Poll: Do you test your code?

#170
post #111

Earlier quoted context omitted.

How do you then know that everything works fine when you do large scale refactoring? Test everything manually? (genuine question, not trying to be snarky).

He doesn't. And I'm not being snarky either. People will say they do, but they don't have any assurance of it. And furthermore, over time they'll learn to stop making these sorts of changes because they don't work, become very cynical about what can be done, and internalize the limitations of not using testing as the limitations of programming itself. And then these people will be very surprised when I pull off a fai…

I get the impression that the code base on which you pulled off the "large-scale invasive refactoring" was not initially under test, else why would the cynical engineers think it could not be done. So did you have to bring the legacy code under test first?
Post reply on HN