From: Shadowfirebird Date: 2008-08-03T06:17:48+09:00 Subject: Re: unit testing advice I wish I had learned this stuff ten years ago. For almost my entire career people have assumed that I can look at their code and tell what it is supposed to do. I can't; no-one can, with any accuracy. All I can do is look at code and say what it *does*. Which is probably not the same thing, or I wouldn't be looking at the code in the first place... But if there are automated tests, *they* will tell you what the code should do. And, better yet, if the programmers have been using them, they will be accurate and up to date. They might not be complete, of course, but two out of three is a hell of a good hit rate in this subject. As far as I am concerned, that's good enough to spark a religious conversion. As for test-driven-design, I think it's a fine ideal. Mostly when I code I know in advance where I'm going, and in that case it pays to use TDD. But sometimes I haven't the faintest idea what I'm doing; I don't know how many classes I need or what jobs go in what classes -- or even if the idea is at all workable. I suspect that TDD isn't of much use in those times. Shadowfirebird. On Sat, Aug 2, 2008 at 9:19 PM, marc wrote: > David A. Black said... >> On Sun, 3 Aug 2008, James Britt wrote: >> > David A. Black wrote: >> >> In fact, one question that has come to intrigue me recently is the >> >> question of whether there are any active programmers who have >> >> literally written code test-first from the time they first learned how >> >> to program onward. I suspect the answer is no -- and if that's the >> >> case, it means that there is no evidence for the position that it's >> >> always, automatically bad to write code without a test. >> > >> > >> > Has anyone ever seen a Learn To Program or Learn Language Blub book that did >> > TDD? I doubt such a thing exists. Instead, people are shown code, >> > encouraged to write code, then (in so many words) told that what they were >> > shown and told is not the right way to code. On the other hand, having a >> > unit test for the 1-liner helloworld.rb seems massively goofy. >> >> The thing is, all the people who argue that testing first is the right >> way to code did not themselves learn to code that way. That doesn't >> prove or disprove anything, but it does make me wonder whether >> teaching someone test methodology right out of the starting gate is >> demonstrably the best way to go about teaching someone programming. I >> tend to think it isn't, though I also think that there are good and >> bad ways to introduce testing into the mix (the best way probably >> being to present it as essentially what they've been doing all along, >> but more structured; and the worst way being the "OK, the fun is over, >> now let's get serious" stuff). > > I started on coding sheets. We wrote tests first. We used to > "desk check" our code too. We had to, it might take a couple of days to > get the cards punched before getting one, perhaps two, compilations per > day. I'm in my forties, so this is ancient, but not prehistoric history. > > That said, I lean towards what David is saying, that it's a skill to be > learned after experimenting/playing with code. After all, we all learn > to speak before we write. And being able to write well takes a lot more > skill than simply being able to write what we say. > > -- > Cheers, > Marc > > > -- Me, I imagine places that I have never seen / The colored lights in fountains, blue and green / And I imagine places that I will never go / Behind these clouds that hang here dark and low But it's there when I'm holding you / There when I'm sleeping too / There when there's nothing left of me / Hanging out behind the burned-out factories / Out of reach but leading me / Into the beautiful sea