> I'm fairly new to unit testing and TDD, but I think I understand the > concept of what they're talking about here. The point is that if you are > writing to the database during unit tests, you're actually testing the > database adapter and abstraction layer, in this case: ActiveRecord, and > not the logic that you have written. ActiveRecord, has been tested > extensively, it would be redundant to test it again. By removing the > database from the testing, you can focus on testing your business > logic... and you have the side benefit of it being quicker, which is > essential for TDD to be a practical way to develop software. I think > what you're describing is considered to be functional testing or > integration test, not unit testing. Functional and integration testing > is equally important, it just occurs at a different level. > > This is one of the *rare* times when I think Ruby got it wrong when > compared with other languages, most other more mature languages Java, > C++, etc.. provide tools to avoid hitting the database during unit > testing for just this reason. I think Rails, and Ruby in general is > heading in this direction too. The next generation of ORM databases like > DataMapper have this sort of thing built in. Hope this helps! > > Cheers, > Eric
Oh, and I almost forgot to mention that Factory_Girl does this as well. Using Factory.build() you only write to memory and not the database. Factory_Girl can also allow writing to the database for functional and integration testing, so you get the best of both worlds. It's one of the pieces in my testing suite. -Eric -- 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 rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
