Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Poll: Do you test your code?

news.ycombinator.com

Post reply on HN
Print view View original

221–230 of 351 posts

Re: Poll: Do you test your code?

#221

Post by angersock »

jerf wrote: post #204
TylerE wrote: post #116

Earlier quoted context omitted.

I'm curious as to what exactly you mean. Can you give some examples? If your're frequently making large-scale changes, I'd spend more time worrying about why you're having such a hard time nailing the requirements down.

A framework previously designed to work on a single device was ripped apart and several key elements were made to run over a network remotely instead. (That may sound trivial in a sentence, but if anyone ever asks you to do this, you should be very concerned.) The framework was never designed to do this (in fact I dignify it with the term "framework"), and tight coupling and global variables were used throughout. Thi…

So, at the end of the day, you never actually did design-from-scratch work, and instead used tests to verify incremental design improvements (key part: verify not create)?

Re: Poll: Do you test your code?

#222

Post by achompas »

tel wrote: post #118
achompas wrote: post #92

Earlier quoted context omitted.

What about NumPy + unittest + all other Python libraries?

NumPy is making pretty strong headway in many communities. It's still not Matlabby enough for the majority, though. It doesn't make a clear improvement, so I think many see it it as just poorly replicating the features of Matlab for free. It's also pretty notoriously difficult to install, especially if you want LAPACK/BLAS. I wasn't able to get it running on many of our servers for that reason and had to revert to Ma…

It's also pretty notoriously difficult to install, especially if you want LAPACK/BLAS.

I almost said "no way!" then remembered how difficult it was for me to get Scipy 0.9.0 installed and verified via tests.

Still, it's like Matlab ("it" being Num/Sci/Matplotlib) plus all of Python. That's a significant improvement over Matlab if you can get it installed.

Re: Poll: Do you test your code?

#224

Post by redsymbol »

I would have liked an intermediate option between "test all" and "test a few critical things". Pretty much we follow the 80/20 rule with unit and integration tests, and it's served me and different teammates well over years of software development.

Re: Poll: Do you test your code?

#225

Post by sfev »

niccl wrote: post #212
fragsworth wrote: post #210

Earlier quoted context omitted.

The process goes more like this: 1. Write some code 2. Test it 3. Debug your code 4. Test it 5. Debug your code 6. Test it ... 39. Debug your code 40. Test it; now it finally seems to work If all your "test it" steps are being done manually, you're being very inefficient. A good unit test can actually make development go by faster with the added bonus of defending your code from changes down the road that might screw…

That's all fine unless you're exploring a solution space. Then the overhead of writing tests which are thrown away _in entirety_ is outrageous. AFAIK TDD really only works if you're either a) prepared to waste a huge amount of time writing tests which will later be completely redundant or b) working to a very clear set of requirements with tools and frameworks you already know intimately.

Sure, but what you're describing is prototyping.

Prototype all you want without tests, but once you've settled on a design & are ready to make it production-ready you should spend time at least writing unit tests for your work or (ideally) take what you've learned & re-apply to a clean design written in a test-first manner.

You might think this is a waste of time, but putting code into production without tests is going to give you more trouble in the long run.

Re: Poll: Do you test your code?

#226

Post by drsim »

redsymbol wrote: post #224

I would have liked an intermediate option between "test all" and "test a few critical things". Pretty much we follow the 80/20 rule with unit and integration tests, and it's served me and different teammates well over years of software development.

This is the same philosophy I subscribe to. It's wasteful to test everything in a non-world-world-is-going-to-end system. Especially if you're running lean and the code may be thrown away in a week.

Re: Poll: Do you test your code?

#227

Post by dennisgorelik »

jerf wrote: post #204
TylerE wrote: post #116

Earlier quoted context omitted.

I'm curious as to what exactly you mean. Can you give some examples? If your're frequently making large-scale changes, I'd spend more time worrying about why you're having such a hard time nailing the requirements down.

A framework previously designed to work on a single device was ripped apart and several key elements were made to run over a network remotely instead. (That may sound trivial in a sentence, but if anyone ever asks you to do this, you should be very concerned.) The framework was never designed to do this (in fact I dignify it with the term "framework"), and tight coupling and global variables were used throughout. Thi…

That's an amazing story.

Few questions:

1) How many lines of code is in that man-century project? Is the number of lines of code ~proportional to the number of man hours, or lines(man-hours) function is ~ logarithmic?

2) How does your typical project look like (or how does that project look like) in terms of testing vs coding? Do you spend few months of covering old code by tests and only then start testing? Or you do "add tests - add features - add tests - add features - ..." cycle?

What's the proportion between time spent on writing tests and writing code?

3) What's the proportion of time you spend directly working (analyzing requirements/testing/writing code) and generally learning (books, HN, etc.)?

4) Do you do most of the work yourself or you mostly leading your team?

5) How do you pick your projects, and when you pick them - what are your relationships with the clients: Fixed contract? Hourly contract? Employment?

Thanks!

Re: Poll: Do you test your code?

#228

Post by shin_lao »

latch wrote: post #14
shin_lao wrote: post #6

Never forget you write software, not tests. Tests are here to increase quality, they have no raison d'être by themselves.

tests are a lot more about design and refactoring than they are about quality.

Redesign and refactoring is often related to quality, aren't they?

Re: Poll: Do you test your code?

#229

Post by route66 »

geebee wrote: post #163
stephencanon wrote: post #56

Earlier quoted context omitted.

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…

Careful though with tests that literally execute every line of code: You tie your test to your implementation. That makes even the slightest refactoring difficult. Better to have unit tests that only care about the functional interface.

Re: Poll: Do you test your code?

#230

Post by viscanti »

niccl wrote: post #212
fragsworth wrote: post #210

Earlier quoted context omitted.

The process goes more like this: 1. Write some code 2. Test it 3. Debug your code 4. Test it 5. Debug your code 6. Test it ... 39. Debug your code 40. Test it; now it finally seems to work If all your "test it" steps are being done manually, you're being very inefficient. A good unit test can actually make development go by faster with the added bonus of defending your code from changes down the road that might screw…

That's all fine unless you're exploring a solution space. Then the overhead of writing tests which are thrown away _in entirety_ is outrageous. AFAIK TDD really only works if you're either a) prepared to waste a huge amount of time writing tests which will later be completely redundant or b) working to a very clear set of requirements with tools and frameworks you already know intimately.

I find I spend significantly more time refactoring/maintaining code than I spend writing exploratory code. It's silly to write tests for prototype work, but once you're actually close to having a working prototype, tests help. Having decent test coverage saves so much more time when refactoring/maintaining.

TDD isn't "THE" way, but test coverage helps. It's not fun (at least not for me), but it's less aggravating than breaking something 6 months down the road in some non-obvious way. I'm human, so I assume I'll screw something up eventually. Having test coverage helps keep me from shooting myself in the foot later.

Post reply on HN