From: Chris Date: 2002-11-25T14:50:06+09:00 Subject: Re: Unit Testing in Ruby for the (Absolute) Novice ----- Original Message ----- From: "David Naseby" Go to http://www.rubygarden.org/ruby?UsingTestUnit Its an excellent intro to the world of test-first development, and unit testing in Ruby. David. ---------------------------- Amen. That site helped me quite a bit. I also am new to unit testing, and am struggling to figure out where to start. My first introduction was in The Pragmatic Programmer (which I bought because I liked the pickaxe book so much, and I thought it was *at least* as good... get it!), which convinced me that unit testing was certainly a good idea. Yep, I should definitely do that. No question about it. But, uh... what do I do?? Whenever I would think about unit testing (which, I'm pretty sure, is rarely if ever done in the gaming industry, which I am coming to believe has the *worst* software practices around), I would think, "Oh, yes, it's a great thing, but this project is really an exception... games are just too complex for something like that. Everything needs to interact with everything else... (how young I was then (last year)...)" Then I thought I would try unit testing on some personal projects (as I was learning Ruby, actually), but again, it just didn't seem like it would work with this particular project... certainly this isn't the sort of program the Pragmatic Programmers were thinking of! At this point, of course, I was starting to think that these were probably all perfect cases for testing, but that I just didn't know how to do it. (Hey, I was inexperienced, but I wasn't stupid.) The problem was, I couldn't think of how you would unit test unless you used totally contrived examples... examples made specifically to show unit testing... What I didn't see was that *that is exactly what you want*! You want to turn your code into 'contrived examples' of testable code! No, that lightbulb didn't really click until several years later (only about a month ago). The best advice for getting your own personal lightbulb to click on: write your tests first. Just a few small ones, nothing elaborate. Instead of coding to get the job done, try testing to see if the job *is* done, and then *just* code to satisfy your tests. (Memorize that last sentence; it has become my mantra.) That's the hard part for me: keeping my head up when I write my tests, and my head down when I write the "real" code. My post-lightbulb realization: You can't ****ing unit test if you don't have any ****ing units! I really think that was my biggest problem: the non-modular code I was starting with. My solution, like I said, was to start with *no* code. It really made a huge difference in my ability to see where I should go. There are still plenty of things I don't know about it, though: - How to test GUIs, for example? (Well, if the code is modular enough, you can test everything but the GUI, which itself probably won't be such a source of bugs...) - How does writing your unit tests first relate to rapid prototyping? How deep does one write one's initial tests? Is it better to test at the higher levels first, using mock objects to work on, then go ahead and code that higher level (which seems to be what rapid prototyping would suggest I do)? Or should I keep trying to write all of my tests first (that being the bulk of the design of the project(?)), then just satisfy my tests right at the end? (I guess it seems like the right way to test, but it doesn't seem like you prototype anything this way.) - Is there a good description of using mock objects anywhere? It sounds nice, but there's nowhere in my brain for it to click into, yet. Chris