I just finished putting the finishing touches on rubyholic and set it free. Check out rubyholic.com! Add your group's info.
Rubyholic was written to help rubyists organize and make it easier for organizers and potential members find each other. Consider it the white pages for the ruby brigades out there. I hope to get it well googled.
Rubyholic was written entirely Test-Driven. I never loaded any of it in a browser before launching the application on textdrive. I learned a lot doing this. A lot.
First, that while I'm very pro-TDD for "regular development", I had a huge amount of cognitive dissidence when it came to thinking of web development that way. C'mon, you tweak a line, save, and reload. I even had an emacs command to reload safari in the background. This is just how it was always done.
Second, TDD on rails is not there yet. It is still hard, but with Eric's help, it is getting better. He handed me some stuff he used for one of his apps and that expanded my functional testing vocabulary by a considerable amount. But we still aren't there for structural testing, partials, ajax, controllers and views. A lot could be done to make testing more of a pleasure.
Third... well, it is 2 AM here. You'll get the third in later installments. :)
Many many thanks go out to: Eric Hodel for pushing me to do TDD and being the perfect pairing navigator; Gianni (yipstar) and Goffrey (topfunky) for making my ugly stuff pretty; Matt (bricolage), Chad, Nathaniel, and Michael (ged) for being early testers (gah! sorry!); and I'm sure many more. Again, it is 2 AM here.
P.S. The server it is sitting on (on textdrive) is being a bit... touchy. Please be nice. I swear it passes all it's tests!
"But we still aren't there for structural testing, partials, ajax, controllers and views. A lot could be done to make testing more of a pleasure."
I agree that there is still plenty more that can be done. However, can you give me some examples of what might be done to make it easier, and cleaner? There is assert_tag and friends, which though verbose, does allow you to do structure assertions.
Also, I have to wonder whether it is really a reasonable expectation to be able to build a GUI application purely TDD, and never look at the finished product. Yes, it can be done (as you have demonstrated), but a visual product is, by definition, one that is meant to be viewed. It is certainly possible to assert that this div went here, or that some table had some CSS class applied to it, but that does not mean you'll get the visually correct result. I have to wonder if this is even possible. There is a human factor to interface design that can't (and, I posit, shouldn't) be removed. It's like suggesting that painters create their masterpieces without once looking at the canvas.
Anyway, not trying to diminish what you've done here--great job, really. And I'm not trying to defend any definciencies that rails may have. I'm just voicing some thoughts I've been having recently on this topic.
"I agree that there is still plenty more that can be done. However, can you give me some examples of what might be done to make it easier, and cleaner? There is assert_tag and friends, which though verbose, does allow you to do structure assertions."
assert_tag becomes very difficult to use when you have more than 500 bytes in your document. Since controller testing and view testing are coupled you can't break down your HTML assertions into useful units where failures will make sense.
Structure assertions are too hard. You can't easily say "I have an h1 followed by an h2 with that followed by a list followed by another h2."
"Also, I have to wonder whether it is really a reasonable expectation to be able to build a GUI application purely TDD, and never look at the finished product."
Absolutely reasonable. It makes you "get real" that much faster. You do a sketch of the page, you write tests that match your sketch, you implement application code to pass your tests.
You'll find out your sketch was wrong or bad much quicker because the tests will be too hard to write. When you find out that your sketch was bad or wrong you are free to radically reshape the sketch and the page and be confident you haven't broken anything. You get this confidence because your seat belt is firmly fastened.
We test how rubyholic behaves, not how it looks. Our tests are answers to questions like: If you go to the group page, what information should the user see? When a user is adding a URL, what information do they need to provide? What order do we display the schedule in? What happens when they give a bad URL?
Having answers for these questions are what makes a website a true masterpiece. Adding a pretty frame will help, but it won't cover up the places you forgot to stop and think.
If you can make your desire for a website concrete with a crayon you can make your desire concrete with a test suite.