Marnen Laibow-Koser wrote: > Avdi Grimm wrote: >> == What >> >> NullDB is a Rails database connection adapter that interprets common >> database operations as no-ops. It is the Null Object pattern as >> applied to database adapters. > [...] >> == Why >> >> NullDB is intended to assist in writing fast database-independant unit >> tests for ActiveRecord classes. For why you would want to test your >> models without the database, see: >> http://www.dcmanges.com/blog/rails-unit-record-test-without-the-database. > > I'm not at all convinced that this is a good way of testing (and in my > experience, ThoughtWorks' software has lots of problems, which could say > something about their testing practices). However, assuming for the > moment that it is good... > [...] >> * It is *not* an in-memory database. Finds will not work. Neither >> will #reload, currently. > > So how is this of any use at all? Normally, when I use tests with > database operations, I do so to confirm that I'm writing to the database > what I think I am. (Sure, I could use RSpec's mocks to test that -- and > then I wouldn't need NullDB in the first place.) By removing the > capability to save records, it seems to me that you've removed any > utility that this might have had. Am I missing something? How do *you* > find this puppy useful? > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > mar...@marnen.org > > Sent from my iPhone
Marnen, 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 -- 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.
