Hi Tim, It seems to me that AR is pretty well tested already. I'm not really all that keen on putting database access tests all through my test base. Accessing the database from a unit test actually makes it an integration test. I'm not saying that is wrong, but it does cause me to ask myself exactly what I am trying to test.
I'm not suggesting that people shouldn't use state based testing, or even that they shouldn't use factories or fixtures. I am suggesting that tests need as much (or more) refactoring love as production code. Too often bad (slow) patterns evolve and are not addressed. When the app is small it doesn't seem to matter. New developers come along and copy the poor patterns they see in the test suite and the problem gets bigger. Eventually parallelising the build seems like the only way forward. If you're lucky, like someone on this thread, you already anticipated that your problem was way too important for serial testing from the get go and have a build rockstar on your team writing complicated build stuff for you. For the rest of us, we now have to hive off valuable developer resources to start working through all the problems involved with parallel building. I'm not saying people shouldn't go parallel. I'm just saying that for many of us, fixing our crappy tests is a much better return on investment. And that is really my point; tests should be seen as a Return On investment problem. I feel certain that all developers are aware that there is no such thing as total certainty with tests. You can only approximate and the principal of diminishing returns will apply. You can put your resources into solving the parallelising problem or you can put them into making your test suite hum, you may eventually need to do both. Adam Boas e: adam.b...@gmail.com m: +61 457 741 117 On 27/11/2012, at 7:40 AM, Tim Uckun <timuc...@gmail.com> wrote: > On Mon, Nov 26, 2012 at 12:18 PM, Adam Boas <adam.b...@gmail.com> wrote: >> Lots of Factory based (database dependent) unit-level specs > > Most rails apps exists solely to shuttle data between the database and > the browser. If you are mocking out these interactions you are not > really testing the most important part of your application. This is > especially true if you have split up your app into multiple classes > all of which are interacting with each other and the database. > > It's expensive sure but it has to be done. > > BTW once I tried putting the database in a RAM disk for testing > purposes, it didn't really help that much so the problem seems to be > AR rather than the database itself. > > -- > 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 rails-oceania@googlegroups.com. > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- 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 rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
