From: James Britt Date: 2008-08-03T03:59:06+09:00 Subject: Re: unit testing advice David A. Black wrote: > Hi -- > > On Sun, 3 Aug 2008, Shadowfirebird wrote: > >> I certainly "get" the idea that it's better to write the tests first. >> Unfortunately my dinosaur brain needed to write some code to prove >> that my class model was workable...! > > I often have to bootstrap myself into an application by getting > something running before I can get my brain into test mode. Certainly > with something like Rails, there's a lot to do before any tests are > written, since you can't write unit tests before you know what your > models are (and generating the model so conveniently writes the test > file for you :-) Isn't the idea of TDD and BDD that you discover what classes and method are needed by writing the tests first? So there *should* be no model in place prior to writing the test; the initial failure of the test is what drive the creation of the model. > > One thing to remember is that TDD is about development, and that not > all instances of entering code on a keyboard are development. And > we've all, I believe, learned an absolute ton from exploration and > experimentation that wasn't part of the process of ongoing application > development. It's important not to feel like you're being > unprofessional or sloppy if you happen to want to try out some code in > a file, or in irb, and you don't write a test for it. > > 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. A more useful view is that TDD and company are for code you plan to keep and maintain, and if you find supposedly transitory code lingering a bit too long you need to consider re-writing via TDD or retro-fitting tests. (And even that should be tempered by the size of the code in question. ) > That's not > meant to be a counterargument to the idea that testing is important > and a good practice. I do wonder whether things get a bit too > doctrinaire at times, though. What I've often heard is that folks (such as myself) will hack out a running version of something as a means of exploratory coding; it's like doing sketches prior to starting The Big Fresco. Then (so some claim), that code is chucked and actual TDD begins: tests, failure, code to make the tests pass. In reality I think most exploratory coders will salvage the nicer parts of the code and tack on unit tests, then move forward with TDD. There may be some bias at play, where the time invested in creating that initial code colors how one determines its quality. > >> What I'm seeing quite clearly now, is that the next best thing is >> writing the tests while *pretending* that you haven't written the code >> yet. >> >> Because the tests should be based on what the code is *supposed* to >> do, not what it does. Look at the code when you want to know what it >> does; but when you want to know what it's supposed to do, look inside >> your head. >> >> I suppose you are all going to say that the tests should show what the >> code is supposed to do? I really like that idea... > > I don't think you have to decide it's one thing or the other. If you > can write tests after you write code, *and* if you feel certain that > the code is as good as it would have been if you had written the tests > first (not all first, but iteratively), that's fine. It's that second > clause that's the issue, though. A lot of people find that writing > tests first helps them get in the "zone" of thinking about *exactly* > what their code is supposed to do, in a very focused way. So it > becomes part of the process of writing the program, not just a way to > put protective armour and/or documentation around it later. That sounds about right. Testing is not the goal; robust, accurate, maintainable code is the goal. -- James Britt www.happycamperstudios.com - Wicked Cool Coding www.jamesbritt.com - Playing with Better Toys www.ruby-doc.org - Ruby Help & Documentation www.rubystuff.com - The Ruby Store for Ruby Stuff