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

261–270 of 351 posts

Re: Poll: Do you test your code?

#261

Post by peeters »

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.

Different levels of tests work here. I usually start with a very high-level test and then as I implement I do unit tests once I have a reasonably high confidence that the units are a good design.

You should often be able to at least create an automated acceptance test for what you're doing (e.g., "as a user I want to click this button and see XYZ"). This is usually extremely decoupled from the implementation so it should survive refactoring. So then do your exploratory code, get the test passing, and then refactor, introducing lower-level tests.

If that doesn't seem doable you might be taking on a task that doesn't have a good set of requirements. Writing code without any concrete use case in mind is fun and all but that kind of code should usually be limited to a prototyping sandbox.

Re: Poll: Do you test your code?

#263

Post by will_ »

The best type of test depends on the type of software being developed. For the sort of statistical software that I have been involved with, I think that system level tests (with synthetic and/or real data) give tremendous bang for the buck. This is particularly true if the data is high volume, relatively homogeneous (in some sense), and most of the top-level interfaces are fixed fairly early on. Many other projects are not like this, and so may benefit more (proportionally) from different approaches to testing.

Re: Poll: Do you test your code?

#264

Post by peeters »

Retric wrote: post #238
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 mostly a beginners problem, I know several people where it's mostly: 1. Write a lot of code 2. Test it 3. It works! 4. Test it 5. It works! 6. Test it 7. It works! ... 15. Test it 16. It works! 17. Are you done? TDD in no way makes 17 any clear, because every test they thought of before writing the code works more or less the first time. And that's the core problem with testing, for a solid developer what fail…

It's not about telling you when you're done a feature. It's about leaving step 17 with a set of tests so that the next person in the code can tell when he's done without doing steps 1-17. And you'd think it slows you down, but it really doesn't. Some advantages of TDD are less context switching (you can test your code without even leaving the code itself) and a high degree of focus (every atomic subtask has a very clear completion criterion: fix the failing test). Those are things solid developers love.

Re: Poll: Do you test your code?

#266

Post by alextgordon »

fragsworth wrote: post #253
mattbriggs wrote: post #241

Earlier quoted context omitted.

I have never seen any half way decent developer write code for more then a few minutes without some sort of feedback, automated test suite or not. You are right that it will work more or less, but they work out the "less" part of that statement sooner rather then later. In my experience, that is a place you get to over time, only the people out of college write code for multiple hours straight, then debug everything…

That's the point I was trying to make. The main benefit comes from eliminating the "run/debug" part of the "code/run/debug" loop. It then just becomes "code/test" where "test" takes all of a couple seconds each time.

But if you don't run it yourself, how do you know it's working? All you know is that the tests pass.

Tests can easily do more harm than good if you let them give you a false sense of security.

Re: Poll: Do you test your code?

#267

Post by secoif »

Testing isn't easy, but it's also a skill you get better at over time. You get a feel for what you should and should not test. You get quick at writing units. Toughen up. Learn to test, noobs.

How can you refactor safely without tests? You can't. How can you safely upgrade your tools (which often change in subtle ways), without tests? You can't.

"Every programmer knows they should write tests for their code. Few do. The universal response to "Why not?" is "I'm in too much of a hurry." This quickly becomes a vicious cycle- the more pressure you feel, the fewer tests you write. The fewer tests you write, the less productive you are and the less stable your code becomes. The less productive and accurate you are, the more pressure you feel. Programmers burn out from just such cycles. Breaking out requires an outside influence. We found the outside influence we needed in a simple testing framework that lets us do a little testing that makes a big difference."

Quote from: http://junit.sourceforge.net/doc/testinfected/testing.htm

Re: Poll: Do you test your code?

#269

Post by angersock »

jaggederest wrote: post #254
angersock wrote: post #221

Earlier quoted context omitted.

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 )?

New hacker news rule: if you haven't done at least 80% of what he's talking about, you can't dick-measuring-contest him. From scratch work is the easier part of programming.

I've done this before, friend. Starting from scratch is indeed easier.

The point I was making was that he used unit tests to confirm his design (as a safety net) and not as a primary design tool.

Post reply on HN