Live data from Hacker News

Poll: Do you test your code?

news.ycombinator.com

151–160 of 351 posts

Re: Poll: Do you test your code?

#151
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…

In this scenario, there should be tests already present covering developer A's portion of the codebase, together with documentation on how to run them (though tests should be as self-explanatory as possible).

In fairness, I recognize that this isn't always the case in the real world. Sometimes you really do need to just blindly attempt to fix something, and there's nothing to be done about it. But it should never become a regular occurrence, and you should never get comfortable doing it. First thing I would do is tell my manager exactly why I'm uncomfortable, and what a conservative assessment of the risk is. If we decide to go ahead with the change anyway, I would create two new entries in the bug tracking system, which should be developer A's top priorities as soon as she returns: thoroughly vet my changes, and DEVELOP A SET OF TESTS.

Re: Poll: Do you test your code?

#152

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…

Look at it this way: you must be testing code as you write it anyway. There's really no other sane way to do it. You make a change, you load the page and see that your change worked, or you call your new function from an interactive interpreter.

Smart automated testing just takes all that extra test work you're already doing and saves it as you go along.

No need to try to invent extra things to test. You just test what you would have tested anyway by hand.

Re: Poll: Do you test your code?

#153

These options are flawed. I am somewhere in the middle of of the first two: mostly integration tests, with critical domain logic unit tested. Certainly not 100% of the app's functionality, closer to 80%

I'm had the same thought Obie. I find high level integration tests provide most of the value for me, with unit testing when I need help with designing code. Having a decent suite of high level tests saves me from having to smoke test the entire app every time I make sweeping changes. If the suite is passing, I know the features are working, at least in the basic cases I was testing for. I still have to do some level…

Interesting... I think I'm with you on this one. There have been a few occasions where I got my test coverage through integration tests rather than unit or functional tests as well.

My real goal is to have tests that will sound the alarm if I've done something that breaks the application. I think this is similar to the "smoke test" you're talking about. Don't want to have to fire up the server and walk through all the use cases - it's very useful to have integration tests that will do this instead.

Re: Poll: Do you test your code?

#154
Early on, I asked most YC founders I met whether they did testing in the early days, and almost all of them said "no". I've also not written tests in the past simply because it's a time investment--why test if you could be working on something entirely different in a few weeks? Code can be very volatile in an early stage startup.

Think it makes more sense the later stage your startup is where you're more certain of what exactly it is you're building.

Re: Poll: Do you test your code?

#155
After reading this thread, I've realized I have to make sure my next employer actually believes in testing.

I don't know how anyone can move forward in a long term application without having regressions done for you in the form of testing.

Re: Poll: Do you test your code?

#156
We actually made a company to do other people's testing: http://CircleCI.com. Really easy Continuous Integration for web apps. Email paul@circleci.com for a beta invite.

That said, I subscribe to the philosophy that testing is only there to support the business, not and end in itself. We often prototype features with no testing at all, because they get rewritten 3 times anyway. Often, writing the tests is what highlights flaws in our logic, so without it we would often we flying blind.

Testing slows down coding by about 135% (yes, more than twice as slow), but makes that time back in spades when you have to work on the same code again, or when changing lower layers (models, libraries, etc).

Re: Poll: Do you test your code?

#157

I don't believe anybody that says they test all functionality. Most? Sure. All? No way. Not in a non-trivial codebase. Article about the group that writes the space shuttle software, sort of relevant?: http://www.fastcompany.com/magazine/06/writestuff.html

The trouble is that the poll doesn't have a middle ground between "all functionality" and "a few critical things". A full run of our test suite literally takes months on a cluster of hundreds of CPUs (obviously, there are also faster versions of the tests which are run frequently). While I have a long list of additional test coverage that I would like to add, what we test is much closer to "all functionality" than it…

I'm also working on some software which tests a lot of functionality, not just 'a few critical things' but certainly not 'all functionality' either.

I'd say that a lot of good responses would have been in between those two.

Re: Poll: Do you test your code?

#158
post #154

Early on, I asked most YC founders I met whether they did testing in the early days, and almost all of them said "no". I've also not written tests in the past simply because it's a time investment--why test if you could be working on something entirely different in a few weeks? Code can be very volatile in an early stage startup. Think it makes more sense the later stage your startup is where you're more certain of w…

I honestly use tests more as a design tool than for testing functionality. After that you end up with a kind of a regression test suite.

It's cool to try to use the API you're building before you build it.

Re: Poll: Do you test your code?

#159

Earlier quoted context omitted.

I cannot supply individual test cases for everything that could possibly be found in the source data. Perhaps not, but you can supply test cases for known problems you might encounter, as well as ones you've solved after they've been encountered.

Yes, that's what I'm doing, but I feel it's a drop in the bucket.

Also don't forget the tests you add help you with the regression tests. The large set of tests would assure you that the new fix you do will not lead to any other bugs that you had fixed earlier.

Re: Poll: Do you test your code?

#160

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…

The point of testing/TDD for me is not (just) about preventing bugs, it is more about having quick feedback. Running a test is faster than waiting until it is deployed and manually clicking around in an application. It is kind of comparable to using a REPL.
Post reply on HN