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

301–310 of 351 posts

Re: Poll: Do you test your code?

#301

Post by MrTortoise2 »

jerf wrote: post #66
TylerE wrote: post #62

Earlier quoted context omitted.

I've seen code in productions apps with comments along the lines of "this isn't optimal, but it's easier to test". Every time I do, I die a little inside. Unit tests are THE most overrated buzzword of the last 10 years.

If you mean that unit tests have accumulated a lot of dogma over the past few years, and you are saying they are "overrated" because you still need to think about how, what, and why you are testing, I agree. If you are using your post as an excuse for not using automated testing at all, I completely disagree. That's the bad kind of developer laziness. On the other hand, I do have to concede that when competing agains…

I agree 100% ;) I'd have to start learning new stuff that i don't necessarily want to get into yet.!

Re: Poll: Do you test your code?

#302

Post by lucian1900 »

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…

I've found tests very useful for refactoring. I can pretty much go wild, as long as the tests pass at the end.

About bugs in production, after you find a bug write a test that exercises that bug. Then make the test pass. That way, you're unlikely to ever have a regression on that bug.

For browser-side UI tests, selenium is very useful.

Re: Poll: Do you test your code?

#303

Post by andrewaylett »

MartinCron wrote: post #284
Oompa wrote: post #280

Earlier quoted context omitted.

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.

That's not strictly true: you'd still like to get reasonably quick feedback, especially if you're trying to make a release.

It's also nice to be reasonably confident that your commit won't break the build, for which you should probably run a good chunk of the tests before committing.

There are some workflows (Gerrit springs to mind) where you can let the CI server work on your code without breaking anything else, but even then there's a cost to the context switch when a test failure means you have to return to a piece of code you thought you'd finished.

Re: Poll: Do you test your code?

#304

Post by djcapelis »

Oompa wrote: post #276
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.

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.

What tests your tests?

Re: Poll: Do you test your code?

#305

Post by maccylo »

specialist wrote: post #273
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…

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…

what book?

Re: Poll: Do you test your code?

#306

Post by colomon »

peeters wrote: post #261
niccl wrote: post #212

Earlier quoted context omitted.

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

"If that doesn't seem doable you might be taking on a task that doesn't have a good set of requirements." Or it might have perfectly good requirements which are very hard to write automated tests for.

Consider (for instance) a program to translate ABC music format to proper sheet music. It's easy to say the basic requirement: "The program has to accurately translate ABC format to legible and easy to read sheet music." But even a start at automating a test for that would require converting a graphical representation of sheet music back to the basic notes, and that problem is at least an order of magnitude harder than writing the original program, without factoring in the "easy to read" bit at all. (PS This is a real issue for me, if someone knows of a decent open source sheet music to MIDI/ABC convertor I'd love to hear about it.)

Re: Poll: Do you test your code?

#307

Post by Retric »

specialist wrote: post #273
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…

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…

You may want to try bottom up coding. The idea is to build things that would make solving the problem space easier and stacking them.

Re: Poll: Do you test your code?

#309

Post by telent »

Chris_Newton wrote: post #174
telent wrote: post #115

Earlier quoted context omitted.

If I have a function/module/method buried deeply inside my system such that testing it requires either ten lines of setup code or backdoors ("special cases and privilege escalation tricks") in the deployed code, that might say something interesting about my architecture in either case. Is the code really only ever going to be called from that one place and in that one way, and if so, exactly how valuable is it? Sure,…

If all your algorithms are as trivial as calculating a weighted modulo 11 checksum, then the sort of case I'm thinking of doesn't apply. However, in real code, we sometimes have to model situations and solve problems that are inherently complex. The algorithms and data structures we work with will necessarily reflect that essential complexity, and ultimately so will our code. Beyond a certain point, I think automated…

> If all your algorithms are as trivial as calculating a weighted modulo 11 checksum, then the sort of case I'm thinking of doesn't apply.

My estimate is that 98% of all programming everywhere is as algorithmically trivial as calculating a weighted modulo 11 checksum - probably more so - and it acquires its bugginess from accidental complexity due to poor factoring, and from conflicts at interfaces. Test-driven development is pretty good, in my experience, at helping ameliorate both these problems.

Of course, that doesn't mean I actually do it 100% or even 80% of the time. I'm happy to agree that it's no panacea: testing threads and UIs are particular pain points for me, and usually I substitute with either Thinking Really Hard or just Not Changing Stuff As Much

Formal proof for me is stuff I learnt at college, forgot subsequently, and keep meaning to reread up on. Thank you for prompting it back up my TODO list

Re: Poll: Do you test your code?

#310

Post by tomgallard »

colomon wrote: post #306
peeters wrote: post #261

Earlier quoted context omitted.

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

"If that doesn't seem doable you might be taking on a task that doesn't have a good set of requirements." Or it might have perfectly good requirements which are very hard to write automated tests for. Consider (for instance) a program to translate ABC music format to proper sheet music. It's easy to say the basic requirement: "The program has to accurately translate ABC format to legible and easy to read sheet music.…

The mistake here is that what you're describing is a functional test, not a unit test.

A unit test for a piece of code like this might be "Given that the time signature for the music is 3:4, the software puts 3:4 in the appropriate place on each line of output".

You then might write a variety of cases testing that it deals correctly with (say) a changing time signature at some point in the piece.

The upside of this is when you try and fix another bug which has a knock on effect on this bit of code, lots of your tests are going to fail- immediately identifying where the problem is (or at least letting you know there is one!)

Post reply on HN