Yes.
You are doing e-commerce, not an AJAX chat application or Blog on Rails. So in theory there is money on the line. I haven't read the book, or any opinions on it, but it's hardline approach to TDD in the context of e-commerce automatically raises my opinion of it.
nuno wrote:
The more I test the less I'm afraid of having my application falling down like a sand castle. I've done many sand castles before, none felt down because I've been lucky.
Thanks to TDD (and Rails, because I've spend so many years trying to setup TDD under J2EE with tools like Cactus without any result
Good lord I thought I was thru with this thread...
My last big project had a major issue (translation: failure) attempting to get Cactus working on a Tomcat project. I had more success TDDing CIAO, but its patron (a highly respected _professor_ of programming) eventually called me a "lunatic" because I kept asking weird questions on their mailing list. I got CIAO (an advanced form of CORBA)completely under control...
...but I couldn't even _install_ Cactus. Each time I tried to configure things, I would get stuck in some hideous error condition. Then, for example, I couldn't tell what the error was because I couldn't turn on logging, because the system wasn't configured just right. That sick joke of a system lead to this page:
http://c2.com/cgi/wiki?ConfigurationHell
That's the anti-Convention over Configuration - refusing to convene _anything_, in fear that the user might override a default.
Someone will have to put a gun to my head to get me to write automated tests for Tomcat again, but if they do, I am ready: With Watir...
...and with a trick or two that are currently up my sleeve, folks! 
PLUS : Tests are now a commercial argument I use to convince my clients/customers to choose me !
Try "I can deploy continuously and deliver daily"...
Richard Conroy wrote:
You are doing e-commerce, not an AJAX chat application or Blog on Rails. So in theory there is money on the line. I haven't read the book, or any opinions on it, but it's hardline approach to TDD in the context of e-commerce automatically raises my opinion of it.
TDD-ing the GUI Layer is very hard, so we have an excuse to slack off on it.
Until someone fixes that.
I've heard of people doing TDD with Selenium. I'm not convinced that having to use a browser to run your tests is not more trouble than it's worth especially for TDD - but people more clever than me seems to like it.
Jacob Atzen wrote:
I've heard of people doing TDD with Selenium. I'm not convinced that having to use a browser to run your tests is not more trouble than it's worth especially for TDD - but people more clever than me seems to like it.
Tip: Can we think of ways to TDD the GUI Layer without creating all of a web server, browser, DOM, etc.?
I have some experience with trying to do automated testing at a higher level than unit testing.
1 - they are much harder to write 2 - it is more difficult to get these tests to exercise all of your code branches 3 - the tests are very brittle with regard to feature changes etc.
TDD really requires Unit Testing. Its the only cheap way to get good test coverage, and its the good test coverage that provides the foundation for all of the other good TDD practices.
On top of this, you can get functional tests, acceptance tests etc. The closer you get to the user, and the further from the 'coal face', it starts to get much more appropriate to use tools like Selenium & WATIR. These tools *complement* your TDD arsenal, but given a choice, you simply can't get TDD benefits without low-level unit testing.
Selenium & WATIR are great tools, but if they are your only tools, then you are not doing TDD.
The view must be dumb. Move all the logic into helpers, now you can test your helpers. There is a helper_test plugin that makes it easy to test.
Check out:
http://nubyonrails.topfunky.com/articles/2006/04/07/test-your-helpers