Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unit testing in Coders at Work

gigamonkeys.com

Post reply on HN
Print view View original

71–80 of 88 posts

Re: Unit testing in Coders at Work

#71

Post by kscaldef »

eru wrote: post #58
dagw wrote: post #48

Earlier quoted context omitted.

One thing I've never really seen discussed is proving unit test coverage. Taking the clojure example above and its unit tests, nowhere does it make any attempt to show that the few test cases chosen provide a complete coverage of all possible bowling scores. Without that what have you really shown? Sure I can look at it and my gut feeling is, yea that should be enough, but I got that from looking at the OCaml code as…

You should have a look at QuickCheck. It's a Haskell library where you (more or less) specify laws that your program should satisfy, and it generates test cases on its own. I found it very useful.

QuickCheck is cool. But don't make the mistake of thinking that it proves that the properties hold universally.

Re: Unit testing in Coders at Work

#72

Post by extension »

dagw wrote: post #48
keyist wrote: post #4

If you enjoyed seeing the contrast in approaches between Norvig and Jeffries, you may also find the following interesting -- calculating bowling scores in 1. OCaml, no tests: http://alaska-kamtchatka.blogspot.com/2009/07/disfunctional-... 2. Clojure with unit tests: http://blog.objectmentor.com/articles/2009/07/19/uncle-bob-j...

One thing I've never really seen discussed is proving unit test coverage. Taking the clojure example above and its unit tests, nowhere does it make any attempt to show that the few test cases chosen provide a complete coverage of all possible bowling scores. Without that what have you really shown? Sure I can look at it and my gut feeling is, yea that should be enough, but I got that from looking at the OCaml code as…

Proving test coverage is just as (in)feasible as proving correctness. This is the elephant in the room for testing: it relies on programmer intuition to enumerate cases. It's easy to neglect a case both in the implementation and in the test. This is why tests are better at finding regressions than new bugs.

Re: Unit testing in Coders at Work

#73

Post by eru »

kscaldef wrote: post #71
eru wrote: post #58

Earlier quoted context omitted.

You should have a look at QuickCheck. It's a Haskell library where you (more or less) specify laws that your program should satisfy, and it generates test cases on its own. I found it very useful.

QuickCheck is cool. But don't make the mistake of thinking that it proves that the properties hold universally.

Yes. But it's closer to that goal than coding up test cases by hand. (If `closer' is a suitable expression for comparing infinite distances.)

SmallCheck and Lazy SmallCheck seem also to be worth a look. But I did not use them, yet.

Re: Unit testing in Coders at Work

#74

Post by eru »

gcv wrote: post #69

As far as testing goes, I have a simple approach. If I just wrote some code and had to poke at it in a REPL with some different inputs to check if it works, then I should take whatever I did and turn it into a test. With a good testing framework, like the one built into Clojure (formerly clojure.contrib.test-is and now clojure.test), it's really easy. I just copy from my REPL and paste it into the appropriate test fi…

Sensible.

Though writing a test case for an evolving API might be of benefit from time to time, because it forces you to use the API (and thus see if it is sensible).

Re: Unit testing in Coders at Work

#75

Post by silentbicycle »

jerf wrote: post #70
10ren wrote: post #47

One day I hope Joel eventually realizes this. Programmers who say they don’t have time to write tests are living in the stone age. This kind of attitude really pisses me off. It's so confident in its condescension and name-calling, I have a little wonder that they might be right. In fact, it's just dogmatic abuse, unencumbered by an objective factual appraisal of the issue at hand. Probably, I should just remember th…

My position on unit testing is, "Have you tried it?", followed by, "No, seriously, have you actually tried to use it for a period of time, not just played with it for an hour?", which I will then follow by... wishing the programmer well regardless of how they now feel about it, because now they've at least got some experience. Unit testing is a big deal. Everybody should try it. Ideally, you should try it with the ne…

It's easier to learn to use the testing tools themselves on an artificial project, but I find that trying to build testing into an existing project teaches you different (and perhaps more useful) things. It really brings in to focus how to write (or rewrite) code to be testable, and you learn much faster when it's actually a huge win vs. when you would just be going through the motions. If a technique only works on (say) blog-post-sized Ruby projects, then that should be a red flag. Testing is a means to an end.

Re: Unit testing in Coders at Work

#76

Post by maryrosecook »

You know what has improved the quality of my code? Having every error on my live servers emailed to me. I feel compelled to fix it because I know that an actual user has had a problem.

I tried to do unit testing for a project. I'd write a method, then write some tests for it. Some observations:

* I thought that writing the tests would give me refactoring ideas for the actual methods. It did not.

* Running my test suite prior to each deploy saved me from shipping a bug once. Once.

* Writing tests is fucking boring.

This was all code that I knew the purpose of in advance. I have no idea how one writes tests when doing exploratory coding.

Re: Unit testing in Coders at Work

#77

Post by eru »

earl wrote: post #41
Aleran wrote: post #21

In all fairness, how can anyone compare Peter Norvig and Ron Jeffries on the same level? One is an AI genius and the other is a XP coach. They are on very different levels intellectually.

Dude, a sudoku solver is really directly solved via brute force search. If a coder can't come up with the brute force algorithm for a 9x9 sudoku board, there's something wrong with that person.

Brute force? You can write a solver in 15 simple lines of Zimpl code (pun intended), that uses state-of-the-art constraint propagation and all that.

http://www.zib.de/Publications/Reports/ZR-05-51.pdf

Re: Unit testing in Coders at Work

#78

Post by geebee »

maryrosecook wrote: post #76

You know what has improved the quality of my code? Having every error on my live servers emailed to me. I feel compelled to fix it because I know that an actual user has had a problem. I tried to do unit testing for a project. I'd write a method, then write some tests for it. Some observations: * I thought that writing the tests would give me refactoring ideas for the actual methods. It did not. * Running my test sui…

"I have no idea how one writes tests when doing exploratory coding."

You're probably already writing tests, especially when you're doing exploratory coding. How much code do you really write before you check to see if something works? You're almost certainly doing something. Maybe it's just a small main program where you validate that some methods are giving you the output you expected, or maybe it's a simple web form that you populate with mock data to verify it's persisting to a database. Unless you wait until the entire functionality is ready before a trial run (and if you're doing exploratory coding, there's no such thing as "ready" anyway), you are writing something to test during iterations.

Instead of throwing these tests away, keep them somewhere and run them periodically. If they break, figure out why - and either fix the code, or change the test. When you're done, you'll have a bunch of unit tests.

(just a quick note - the process I described above works extremely well for some situations, but poorly for others. Some frameworks make it a real hassle to write unit tests. The process I described also is not TDD, it's more of a write a little, test a little approach, which feels more natural to me. I also don't really like to use TDD, especially for exploratory coding).

Re: Unit testing in Coders at Work

#79

Post by maryrosecook »

geebee wrote: post #78
maryrosecook wrote: post #76

You know what has improved the quality of my code? Having every error on my live servers emailed to me. I feel compelled to fix it because I know that an actual user has had a problem. I tried to do unit testing for a project. I'd write a method, then write some tests for it. Some observations: * I thought that writing the tests would give me refactoring ideas for the actual methods. It did not. * Running my test sui…

"I have no idea how one writes tests when doing exploratory coding." You're probably already writing tests, especially when you're doing exploratory coding. How much code do you really write before you check to see if something works? You're almost certainly doing something . Maybe it's just a small main program where you validate that some methods are giving you the output you expected, or maybe it's a simple web fo…

You're right: I write a little, do a test run of the code to see what comes back, fix it if it doesn't work, write a bit more and so forth. And I see how saving those little tests could be useful.

Re: Unit testing in Coders at Work

#80

Post by undees »

tptacek wrote: post #32
mahmud wrote: post #28

Earlier quoted context omitted.

Enlighten us folks who aren't methodology scenesters. What is wrong this Uncle Bob guy?

I don't know him from Adam, but his "TDD-based" bowling attempt in Clojure seems like a microcosm of that other guy's Sudoku solver in Ruby.

Well, except that the bowling scores thing had a clear spec from the beginning, and was an easier fit for a blog post. The Sudoku thing seemed more like thrashing around in the how-to-represent-data space to avoid thinking about the algorithm.
Post reply on HN