Phlip wrote: [...] > > RSpec is for BDD, like FIT or FITnesse. I would not say that FIT is a BDD tool, at least the way I understand that term.
> It's for communicating with your > business-side analysts about all your features. No. That's what a tool like FITnesse or Cucumber is for. Perhaps your usage patterns are different, but for me at least, RSpec is for describing the behavior of modules, but at a much more technical level than business-side analysts would be interested in. I can't see using RSpec for business-domain tests at all! > For raw development, it > adds > clutter to the syntax without adding much new innovation to the test > flow. How so? I use RSpec for all raw development, largely for two reasons: * I like the syntax. * I like the focus on external interface rather than (Test::Unit's orientation toward?) internal behavior. Where's the clutter? I really don't understand. Test::Unit feels *far* more cluttered to me, or did the last time I tried it. > > And, yes, all the developers are eating it up like popcorn... Sure! It's fun to use. :) [...] > > And it bears repeating that TDD requires writing new tests and > _watching_them_fail_, before adding the tested code. Don't just go write > the > test and then write the code. Don't write the code and then get around > to > testing what you got. Only write new code in response to failing tests. I agree wholeheartedly (although in practice I'm not always as good at this as I should be). [regarding fixtures] > I _enjoy_ their fragility (in their current incarnation). It forces you > to > review your tests. I *really* don't understand this. Could you clarify? > > If anything in TDD is fragile, or leads to too much debugging (p > statements), > revert and try again. Doesn't this contradict the previous sentence? > TDD makes fragility an asset. Doesn't *this* contradict the previous sentence? [...] > Again, use the database to provide ready-made objects, and TDD your > find() > statements at the db. The decoupling will come, and "don't hit the db in > testing" is all but a myth. (Darn you, Mike Feathers!) It's probably a very good general idea (or ideal), but Rails ActiveRecord is too intimate with the DB to make it practical. I *do* think it's worth not having the tests *overly* dependent on the DB, though. <sarcasm>But Jay Fields says that Rails tests shouldn't touch the DB. That's reason enough to agree with you that it's a myth.</sarcasm> > >>> Writing tests is easy when you know how to write them and which tools to >>> use. >>> >>> Remember to have fun. If you are not having fun (even writing tests) >>> then something is wrong. >> >> :) > > Yep. Tests should be easier and easier to write, until you feel guilty > and think > they must not be doing anything for you. I like that. But Master Phlip, I still think my tests are significant...I guess I have not yet achieved enlightenment! > > -- > Phlip Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
