Live data from Hacker News

Poll: Do you test your code?

news.ycombinator.com

281–290 of 351 posts

Re: Poll: Do you test your code?

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

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…

I do strict TDD when I can, and I consider spiking out things part of the process. If I need to approach a problem that I don't know how I'd solve just yet, I create some sample code I later trash and do a lot of work in the Ruby console.

Then, once I've gotten an idea of the problem, I can start writing out some pending tests that help me figure out structure, and then I'll start into the strict TDD loop of write a bit of test, watch it fail, make it pass, write more test, etc.

Re: Poll: Do you test your code?

#284
post #280

Earlier quoted context omitted.

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.

If they are run by a continuous integration server on check in, it kind of doesn't matter how long they take to run.

Re: Poll: Do you test your code?

#285
post #108

Testing is really the last stage. Few software suites get there. Yes, yes, I know you're supposed to build with it in mind from day 0. And if you do that, you may never get to the finish line. You exert every ounce of energy you have to making a viable product. You worry about everything else afterward.

Nope! You should be writing your tests along with your code. Not "keep it in mind" actually write them. My first step in a new project is `mkdir spec`.

Re: Poll: Do you test your code?

#286
Isn't actually running your program and checking if it works a form of testing?

The term "test suite" seems to refer to formal testing techniques like creating unit tests and the like. I don't do that. But I do test my program on every functionality by running and checking if it does what it's supposed to do. Does that qualify as testing?

Re: Poll: Do you test your code?

#289
One other beneficial side effects of having an automated test suite is that they come in handy during any profiling one need to do against the code base. Trigger the automated test suite from the profiler and analyze its output to any performance bottlenecks in the codebase.

Also the practice and triggering the of automated tests regularly (continuous integration) and tracking the time it takes for the tests to run helps to detect early in the development cycle if any of the changes made were suboptimal. All environmental factors being equal a new small feature implemented shouldn't drastically increase the time it takes to run the test suite.

Post reply on HN