Stubbing does not have to contradict the 'R'. Stubbing isolates of the code under test. This is great for unit tests, where a *unit' of code is the thing being tested. *Not* every layer under it. If one of my unit tests fails, it's because the code is broken *at the level that I'm testing*, not deeper in the stack.
That does not mean never running automated tests with the full stack - those are *integration* tests. However, due to Rail's tight coupling of the models and the database layer I will concede that there are times when you have no choice but to hit the database (e.g. for testing CRUD operatios and testing the result of a named scope that relies on an aggregation performed in a database query - you need to test that named scope, and if the work is happing in the DB then you'll need it for the unit test) On 26 August 2011 15:49, Dmytrii Nagirniak <[email protected]> wrote: > 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. > -- James -- 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.
