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

291–300 of 351 posts

Re: Poll: Do you test your code?

#291

Post by tbsdy »

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 that. I wrote a fairly complex piece of code in, of all things, TSQL, and as the logic was unfortunately in the stored procedures and functions I actually found that the unit tests I did for the more granular functions saved me a lot of time. This was because I would make a change to the logic of a function that other functions/procs relied on and the. All of a sudden I would find that a whole bunch of tests on functions that worked before started failing. I'd never have known this without the tests that DID work previously. Saved me a lot of time I can tell you :-)

Re: Poll: Do you test your code?

#292

Post by tbsdy »

alextgordon wrote: post #266
fragsworth wrote: post #253

Earlier quoted context omitted.

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.

But surely if you have written a unit of code, you should at least know a. What valid input the code should have, b. what output the code should return, and c. What you want he code to do! If you know these things, then wouldn't it be easy enough to write tests for at least these conditions?

Re: Poll: Do you test your code?

#294

Post by gendoikari »

mattbriggs wrote: post #279
alextgordon wrote: post #271

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

I think most of you guys missed the point. Writing tests is very important WHILE writing code, to write it better. We MUST write tests not only to catch regressions, to be sure that certain invariants will be manteined. But we write tests to check if we are writing good code. I need to write a class to do some stuff. The test is the first user of this class. If I cannot write the test very fast, and I see that I'm spending a lot of time doing it, this means that my class is poorly designed, is not flexible, is not very reusable. Maybe I'm doing something wrong with my app design. If I'm writing good code, reusable and clean code, testing is easy and fast. Testing help me to check immediately what's going wrong with the code, not only in term of bugs.

Re: Poll: Do you test your code?

#298

Post by vishgm »

haar wrote: post #258
harel wrote: post #195

Earlier quoted context omitted.

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.

Even if you test manually what you just changed, in a relatively complex codebase how can you guarantee that your changes haven't broken behaviour in a separate yet related aspect of the system? This is what I find the major advantage of a comprehensive test-suite to be, I don't have to worry as much about breaking any part of the system as a whole - if my suite passes, then I know everything I've worked on so far wo…

so true!!

Re: Poll: Do you test your code?

#299

Post by sbarlster »

Unit tests. Tick.

Integration tests. Tick

Automated acceptance tests. No Tick.

Tried to sell concordian as a framework to support BDD - but that is a hard x-discipline change which would have required more effort to push through. So as a short term measure have started to write/express unit tests using a standard BDD style - GIVEN x WHEN y SHOULD z. This has helped to assign value to each unit test. There is now a direct connection between the test name and acceptance criteria specified in a user story.

Re: Poll: Do you test your code?

#300

Post by shawabawa »

ericHosick wrote: post #125
Jach wrote: post #106

I test things that seem like they're important to test. I also do a lot of manual checking which boils down to "does it work?" When the manual checking is too tedious I'll write code to help. I don't do unit tests (but I don't think most people who think they're doing unit tests are, either). In general I have three big problems with the philosophy of testing, especially test-first. (Though I don't feel incredibly st…

Asking if the tests are correct is really asking if the requirements are correct. If this happens a lot it means developers are writing code before they really understand the requirements. If developers have to re-write behavioral level tests a lot, it probably means the product owner/project manager/managers/stake holders/etc. are changing the requirements. A lot of pain should be felt gathering and verifying what t…

> Asking if the tests are correct is really asking if the requirements are correct.

Not really. Tests can have obscure bugs just like any other piece of software. If a test fails it could very well be a bug in the test, not the code being tested.

Post reply on HN