1. Why are we suddenly discussing a two year old post here? Clue me in. 2. Myron Marsten is now the maintainer of NullDB. See http://github.com/nulldb/nulldb
3. I'm not really interested in rehashing the arguments for NullDB. Enough teams are happily using it that I had to transfer maintainership over to someone else so that I could focus on other projects. I suggest you go on the RSpec-User's mailing list and ask if someone wants to explain why they use it. But briefly, I'll say this: if you are including the DB, you aren't Unit Testing. Period. Your tests might be *useful* and *important*, but they aren't Unit Tests. A lot of Rails practices, while overall encouraging more TDD, have muddied the waters WRT to what is a Unit Test. A Unit test isolates a *single* object or method from *all* of its collaborators, and tests the inputs of that object or method in a vacuum. If it doesn't isolate, it's not a Unit Test. Which, again, is not to say it's a bad test. These days I drive my app development almost exclusively from high-level full-stack Cucumber acceptance tests, and only drop down to the Unit level when there is some particularly interesting/tricky logic to be described. And sometimes I write functional level tests that include the DB but not the UI level. But I don't call them unit tests and I keep them separate from my unit tests. If you are interested in this kind of Unit Test discipline - which, when followed, tends to make for smaller, tightly-cohesive objects - NullDB may be for you. Especially because it enables you to test (for instance) logic in after_save hooks which would otherwise force the DB to get involved. -- Avdi -- 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.
