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.
Unit testing in Coders at Work
21–30 of 88 posts
Re: Unit testing in Coders at Work
#22In 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.
Solving Sudoku isn't exactly rocket science. I can understand if you don't have the cleanest, most elegant solution in the world, but if you can't even make a tiny bit of progress toward writing a Sudoku solver in a few hours, then I don't think you have any business holding a programming job, much less telling other programmers how to do their jobs.
I mean, those Ron Jeffries blog posts read like someone who has never solved a non-trivial programming problem in his life. He literally makes no headway on any difficult part of the problem, and he spends what appears to be the better part of several hours working hard to get nowhere on code that does very little. If someone is listening to him about how to approach programming projects, I've got a bridge to sell that man.
Re: Unit testing in Coders at Work
#23Earlier quoted context omitted.
Why exactly is unit testing of GUI components a waste of time?
Because it takes a lot of time and effort but does not provide much benefit.
I've found that it's often worth unit-testing functionality that depends upon complex combinations of GUI state. For example, "Show the menu only when there is a selected bar and the baz list contains at least two items that can be foozled together." These interactions are very often wrong, and even if you code them right, it's nice to have a record of what the spec was so when someone comes along and says "I can make this code much cleaner if I eliminate the check for foozling" (or worse, they change the definition of foozling), the test breaks and you remember there was a reason you put it there in the first place.
I find that it's a waste to test things like appearance, position, labels - basically anything that should be in CSS or other declarative specifications. But UIs often have quite a bit of actual logic in them (ironically, because real humans are often strikingly illogical), and that should all get tested.
Re: Unit testing in Coders at Work
#24In 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.
Solving Sudoku isn't exactly rocket science. I can understand if you don't have the cleanest, most elegant solution in the world, but if you can't even make a tiny bit of progress toward writing a Sudoku solver in a few hours, then I don't think you have any business holding a programming job, much less telling other programmers how to do their jobs. I mean, those Ron Jeffries blog posts read like someone who has nev…
In fact, solving Sudoku puzzles was a programming assignment given in my first year of undergraduate study. We were given input/output specifications, and told to write in C++. That was it.
Seeing as how most of the class passes, I assume almost any joker can write a half-decent sudoku solver if sufficiently motivated.
Re: Unit testing in Coders at Work
#25The most important lesson to learn here is that all code, including tests, is a means to an end. A lot of people geek out about new programming languages, object oriented design, automated testing, TDD, XP, and various other methodologies du jour. If those things help you achieve your goal, that's great; but it's important to remember that they're (usually) not your goal in and of themselves.
I don't think jwz would say that unit testing is a bad idea. What he was trying to say when he dismissed them was that they were focused on making a browser, not on making a nice piece of code.
Similarly, Norvig was focused on solving sudokus, not on exploring methodologies that might be used to write the code which solves sudokus.
Re: Unit testing in Coders at Work
#26If 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...
Unclear on how anybody can cite the author of the latter with any kind of reverence, but I see that happen all the time.
This seems unfair. (a) OCaml != Clojure; maybe the former is better for this problem. (b) Uncle Bob writes I’m trying to learn Clojure, i.e., he admits he's brand new to the language and doesn't (yet) know what he's doing. So, maybe cut the guy some slack?
Re: Unit testing in Coders at Work
#27That was a fabulous analysis. For my part, I can't quite figure out why people seem to get emotional about TDD one way or the other. If it helps you, great. If not, ditch it. Do people work in environments where they'd like to avoid TDD but are forced to work that way? Or vice versa?
Do people work in environments where they'd like to avoid TDD but are forced to work that way? Or vice versa? Yes. Unfortunately, it's one of those things that only works well if you have total buy-in from everyone on the team. Maybe we should avoid methodology that requires too much of that. Reminds me of how communal living only works if everyone pitches in. How about a methodology that works entirely off of inhere…
Can't the teams just decide this by consensus?
There're a bunch of these practices that require total buy-in from a team. Things like "Are we going to use bugtracking software to coordinate who's doing what?" "Are we going to have daily stand-ups?" "What'll the conventions be for X?" etc.
On the projects I've been on lately, the answer has usually been "Fine by me. Let's give it a try and see if it works out." And if it's not working out, we don't do it anymore. But oftentimes they really do help, and we end up introducing the same practices to our next project.
Re: Unit testing in Coders at Work
#28If 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...
Unclear on how anybody can cite the author of the latter with any kind of reverence, but I see that happen all the time.
Enlighten us folks who aren't methodology scenesters. What is wrong this Uncle Bob guy?
Re: Unit testing in Coders at Work
#29The most important lesson to learn here is that all code, including tests, is a means to an end. A lot of people geek out about new programming languages, object oriented design, automated testing, TDD, XP, and various other methodologies du jour. If those things help you achieve your goal, that's great; but it's important to remember that they're (usually) not your goal in and of themselves. I don't think jwz would…
"TDD, XP, and various other methodologies du jour. If those things help you achieve your goal, that's great; but it's important to remember that they're (usually) not your goal in and of themselves."
When you are an agile "coach", Scrum Trainer etc, TDD, XP , Scrum etc are your goals!
Re: Unit testing in Coders at Work
#30Nothing can excuse testing a non-solution, so I won't defend it. But correct code, code that does solve your problem, isn't always pretty: sometimes it's straw instead of gold. And testing is orthogonal: you can write untested gold, untested straw, tested straw, or tested gold. Sometimes you're lucky and untested gold bursts fully-formed like Athena from the head of Zeus. Otherwise, be glad for testing, which lets you turn untested straw into tested straw, and thence, via a refactoring Rumpelstiltskin, to tested gold.