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

311–320 of 351 posts

Re: Poll: Do you test your code?

#311

Post by tolitius »

the answer to "how much" is aways "it depends".

* tech stacks evolve changing the amount of testing that is needed => most of the stacks allow to only focus on the "meat" of the logic, rather than things like integration (Spring Integration / Camel), network (Netty), cache (Redis) or even data structures (various language built ins).

* human is getting better with years of coding => I spot flaws and mistakes during code reviews N times faster than I did 10 years ago. I code in little pieces (usually functions), which "talk" back to me immediately even before they are finished.

* REPL is getting really good => Clojure, Scala, Ruby, Groovy, etc.. REPLs save lots of time and prevents mistakes: where a 5 minutes REPLay session reveals a nice and polished approach a lot quicker than a "let's try this / now rerun the test" formula.

* Domain knowledge and "'ve done this exact thing before" greatly impact amount of testing needed => e.g. deeper domain knowledge allows for [better] tests, while no domain knowledge requires lots of prototyping (even if you think it is the "real thing" at first, it is not, it's a prototype), and would greatly suffer from a large number of tests, as most of the time will be spent rewriting test instead of learning the domain.

In the end, the rule of thumb I always use is "do whatever makes sense". I don't buy TDD, ADD and other DDs. They are fun to read about, but they are too removed from the "real thing". If any DD term is needed, what I use is MSDD => "Making Sense Driven Development"

Re: Poll: Do you test your code?

#313

Post by gbog »

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.

A couple of seconds is too long. I run a small test suite in a couple of microsecs every time I save a file, and save my file at every change. When a task is done I run all the tests.

Re: Poll: Do you test your code?

#314

Post by gbog »

jakejake wrote: post #126
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…

My approach to testing is not to be obsessed with the latest, greatest framework or 100% code coverage. I try to start with just one or two tests to actually help do things that are tedious or require multiple steps. It takes some time to automate a good test but once you do it immediately starts saving time because you don't have to run the same sequence a thousand times while developing. You can think of it more li…

Testing is like jumping in cool water, one find so many reason to not do it beforewards, but one is so happy to have done it afterwards...

Re: Poll: Do you test your code?

#316

Post by Chris_Newton »

telent wrote: post #309
Chris_Newton wrote: post #174

Earlier quoted context omitted.

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

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

I think it depends a lot on your field.

If you're working in a field that is mostly databases and UI code, with a typical schema and most user interaction done via forms and maybe the occasional dashboard-type graphic, then 98% might even be conservative.

On the other hand, if you're doing some serious data munging within your code, 98% could be off by an order of magnitude. That work might be number crunching in the core of a mathematical modelling application, more advanced UI such as parsing a written language or rendering a complex visualisation, other I/O with non-trivial data processing like encryption, compression or multimedia encoding, and no doubt many other fields too.

Generalising from one person's individual experience is always dangerous in programming. I've noticed that developers who come from the DB/business apps world often underestimate how many other programming fields there are. Meanwhile, programmers who delight in mathematical intricacies and low-level hackery often forget that most widely-used practical applications, at least outside of embedded code, are basically a database with some sort of UI on top. And no, the irony that I have just generalised from my own personal experience is not lost on me. :-)

This can lead to awkward situations where practical problems that are faced all the time by one group are casually dismissed by another group as a situation you should never be in that is obviously due to some sort of bad design or newbie programmer error. I'm pretty sure a lot of the more-heat-than-light discussions that surround controversial processes like TDD ultimately come down to people with very different backgrounds making very different assumptions.

Re: Poll: Do you test your code?

#317

Post by rezna »

I answered "We'd like to do more testing but it's too much overhead" but it's not really true. The true answer would be "We'd like to do more testing but it's hard to convince people to really write tests."

Re: Poll: Do you test your code?

#318

Post by colomon »

tomgallard wrote: post #310
colomon wrote: post #306

Earlier quoted context omitted.

"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 i…

Who said anything about unit tests?

But okay, is it really so much easier to write a test which just tests changing the time signature? It's still going to require doing OCR. And if I'm really testing it, I've got to make sure the time signature change comes at the correct point, which requires OCR on the notes around it. Also the bar lines (to makes sure the time signature change is reflected in the notes per bar and not just by writing a new time signature out and otherwise ignoring it).

Now, it's perfectly reasonable to have unit tests that the code correctly recognizes time signature changes in ABC format. (And it looks like I forgot to write them: I see inline key changes in the tests but not inline time signature changes.) But that's only testing half of the problem; and it's the easier half by far.

Re: Poll: Do you test your code?

#319

Post by Chris_Newton »

tomgallard wrote: post #310
colomon wrote: post #306

Earlier quoted context omitted.

"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 i…

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

Don't you still have the same problem colomon described here, though? Testing your stated condition "the software puts 3:4 in the appropriate place on each line of output" still implies some form of image recognition on the graphical output.

Re: Poll: Do you test your code?

#320

Post by colomon »

wpietri wrote: post #85
amouat wrote: post #77

Earlier quoted context omitted.

That's not entirely fair - you haven't tested the branches or statements inside the sin function. However, even if the sin function is already tested elsewhere, you will still need further testing to ensure that you are calling it correctly (e.g. not confusing degrees and radians). EDIT: Yes, I read it wrong - clearly need coffee...

Perhaps you need to read it a little more closely? For the given function, he has indeed tested all the branches and statements.

Also, it's the simplest thing that can possibly work! (And for very small values of x is also the best possible implementation.)
Post reply on HN