> > The thing that annoys me is I read through a book like Continuous > Testing (http://pragprog.com/book/rcctr/continuous-testing) and they > say you should be aiming for your tests to run fast enough to have > hundreds running per second.
I don't take it all too literally. The FIRE acronym is advocated in the book. Where F=Fast I=Informative R=Reliable E=Exhaustive To me, stubbing contradicts the R (you replace part of YOUR system; how can the testing be reliable as it never runs your code). FAST means that "the tests in our suite need to be fast, so that we can run them after every change". And to me the main barrier currently is Rails start-up time rather than time to run a test. With Autotest/Guard you can run your test after you save the file. It is fast enough. The book itself describes how to break dependency doing HTTP request to Twitter. This is totally fine. But I would love to hear how people really break dependency on database in Rails. You probably need to explicitly separate data access layer and the logic. It would at least double the amount of code and overcomplicate it. In turn you would need to write more test (by factor of 2-3?). So you would end-up with the system of 5000 tests that run for 60 seconds. Or you can have less complex system with same test coverage and 2000 tests that run for 60 seconds. I would probably choose 2nd. (P.S. I am exaggerate a bit, but you get the point). -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en.
