> I _enjoy_ their fragility (in their current incarnation). It forces you > to review your tests.
Fixtures make tests really slow, and they will eventually not reflect the actual model if you forget to update some attribute you changed. Moreover, you have to actually open the fixture file to know what's in it. I prefer to setup each test inside the test method so that I can immediately predict what should be the end result. > The decoupling will come, and "don't hit the db in > testing" is all but a myth. (Darn you, Mike Feathers!) Although everybody talks about him, I still don't know who he is... Anyway, I got the idea of not hitting the DB from Jay Fields, and from my own experience. Havin super fast tests is so enjoyable. > Absolutely false. Mock almost nothing - the clock, the wire out of your > workstation, and system errors. I think nobody is right nor wrong. The truth lies somewhere in between. I know that mocking, subbing and using unsaved objects can let in some bugs in my tests, but on the other hand it speeds up the tests. So I guess some objects can be mocked/stubbed/unsaved in order to save time, and some objects must be saved in order to make sure they are valid and legit in DB. What's funny is that in 2009, there is still a lot of debate about the testing workflow, although programming has been around for a few years :-) -- 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 -~----------~----~----~----~------~----~------~--~---
