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

271–280 of 351 posts

Re: Poll: Do you test your code?

#271

Post by alextgordon »

mattbriggs wrote: post #241
Retric wrote: post #238

Earlier quoted context omitted.

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…

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…

> 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

I do this all the time. Two reasons:

1. I can keep in "the flow" for an extended period of time. This is more important if the code is especially complicated. If I have to stop every few minutes to fix trivial errors, it's easy to forget important details of how everything is supposed to work.

2. Not having any feedback forces you reason about the code before writing it. It's very easy to fall into the trap of writing code, then waiting until it is tested to find the errors. Thinking before writing is the fundamental skill that TDD encourages, but you don't need TDD in order to do it.

> only the people out of college write code for multiple hours straight, then debug everything afterwards.

Knuth wrote TeX in a notebook and did not test it for a good six months afterwards, though I am not aware if he was out of college at the time.

Re: Poll: Do you test your code?

#272

Post by 3am »

diminoten wrote: post #144
callmeed wrote: post #113

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…

How do you feel about regression testing? Maybe instead of "writing" tests for potential bugs, you write tests for bugs you've found already.

Regression testing is when you check that new code doesn't break existing functionality. It's preventative, not reactive.

Re: Poll: Do you test your code?

#273

Post by specialist »

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…

Not groking TDD, I literally worked my way thru the book, doing each and every step, just to get the gist of the experience.

TDD works fucking great. If you know what you're doing.

Alas, that's a big IF. Most of the stuff I do, I'm just figuring shit out.

Mostly, like when designing a new library, I work outside-in. I imagine how I'd want to do something, writing the client pseudocodeish stuff first, and then trying to make the implementation support my idealized programming mental model.

I end up throwing away A LOT of code. Getting something short and sweet takes a lot of experimentation, most of which are duds.

Though my personal approach of outside-in is trivially like TDD, it's not nearly as rigorous. Were I to be as thorough as TDD, I'd be spending all my time writing tests. Which seems pointless, for code I'm like just going to throw away.

Anyway. Much respect for the guy who wrote that first TDD book. It's one of the few methodological strategies that works as advertised.

Re: Poll: Do you test your code?

#275

Post by IanMechura »

I don't find an applicable selection for my company.

We write and run so many tests that it is a full time job curating the test suites that should be run prior to code delivery. Basically, if you don;t like writing tests you will be miserable at our shop.

The tricky part is keeping testing standards consistent when you get beyond 30 or 40 developers.

Developers tend to be more opinionated about testing practices than even editor selection and curly brace placement.

Re: Poll: Do you test your code?

#276

Post by Oompa »

harel wrote: post #195
ef4 wrote: post #152

Earlier quoted context omitted.

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 wh…

But then you'd still do the manual test after you complete your code. Nobody (I hope) codes blind hoping it would work or caught later by a test suite. Test suits don't reveal everything. Only what you tested for.

Then you didn't write good enough tests. I have deployed code that thousands of customers see without manually testing it. If my tests are green, I'm confident in deploying my code.

Re: Poll: Do you test your code?

#277

Post by Oompa »

eric-hu wrote: post #236
sunir wrote: post #124

Earlier quoted context omitted.

People write and play with test frameworks because they are procrastinating from writing actual tests. Think about it. Just use Test::Unit and move on with your life. Write some tests. That's what counts.

I'm working on a single page app that's about 30% Rails and 70% Coffeescript/Backbone.js. Test::Unit is practically useless for us since users never hit any plain HTML pages besides the login page. Imagine the current HTML5 Pandora having bugs with one particular song in Chrome only. How do you test for that using Test::Unit?

Testing with front end javascript is more difficult due to different interpreters, much more variation in environment, etc. That doesn't mean you can't have tests for your core business logic at least in something like Vows or Mocha.

Re: Poll: Do you test your code?

#278

Post by IanMechura »

WOW! I must say that I am actually surprised how many people have replied that they do little or no testing.

Perhaps this is because I am in the enterprise development world as opposed to the start-up world.

The cost and frustration involved in delivering a critical bug into a QA or production environment is much higher than the cost and frustration of writing and maintaining tests.

Every action in business has a cost associated with it. The more people involved (customers, UAT, Managers, etc.) the higher the cost. The sooner you can discover the bugs and fix them the less people are impacted the lower the cost.

This is how you make yourself as a developer more valuable and justify your high salary/rate by ingraining habits into your daily routine that reduce costs for the business.

In this I also imply non monetary costs, like the personal costs involved in asking a VP to sign off on an off-cycle production release due to a bug that could have been identified by a test prior to the integration build.

Re: Poll: Do you test your code?

#279

Post by mattbriggs »

alextgordon wrote: post #271
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…

> 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 I do this all the time. Two reasons: 1. I can keep in "the flow" for an extended period of time. This is more important if the code is especially complicated. If I have to stop every few minutes to fix trivial errors, it's easy to forget important details of how everythin…

> 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

Reading that again, I'm sorry if it came off as sort of attacky, but I really meant that as a "from my personal experience with the people I have worked with over my career" type qualification :)

I can buy #1, but only when it is something you've done a bajillion times before. When you are getting feedback every few minutes, you know exactly what introduced the problem, and don't waste time tracking things down. If you do miss something fundamental and have several hours work behind you, you tend to be more inclined to hack out something to make it work, where if you catch it a few minutes in, you can adjust your design to take it into account. I also find I can keep in the flow pretty easily with constant feedback, and I use simple todo lists to make sure I don't lose track of things.

As for 2, at least for me, I don't think there is any comparison between thinking about how things should work, and knowing if things do work before writing. TDD is definitely not a replacement for deep thought and planning, but I think that is a different beast then working out the details as you are writing them, which is where it comes into play

> only the people out of college write code for multiple hours straight, then debug everything afterwards.

I sort of did it again there, I should have qualified it more :) In my experience, the better programmers I have worked with, paired with, and watched code in videos will get feedback as quickly and often as makes sense, be it with tests or without them. I know if I wrote TeX in a notebook, it would be a guaranteed unmitigated disaster :)

Re: Poll: Do you test your code?

#280

Post by Oompa »

MartinCron wrote: post #169
callmeed wrote: post #113

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".

I'm pretty far into the extremist side of TDD, and I'll say that there is a thing as TOO many tests. Your test suite needs to run fast to be really useful.

If you have thousands of full stack integration tests that takes an hour to run, you're not going to run them as often as you should be, if at all, ad might as well delete them.

Post reply on HN