News for hackers. Stuff that matters.
Re:How deep are your unit tests? by kibibyte on Monday December 10, 2012 @04:45AM (#4898293)
That's what I thought until my first summer internship at a Rails shop. Our unit test suite could take a very long time to run (on my Macbook Air dev machine, it would take 15-20 minutes to run). The slowdown came from testing ActiveRecord models with many dependencies, and that we were creating sample models. As a result, our tests hit the test database multiple times, which made them slow down.

Our solution was to start mocking as many models as we could, which really did improve test runtime.

(Slight edit: after reading the other replies, now I really understand what integration tests are for.)

Re:How deep are your unit tests? by Firehed on Monday December 10, 2012 @04:49AM (#4898302)
How many issues do you think may be hidden by mocking out the database layer? It's easy to write bad data due to a subtle bug in a query builder for example and then write garbage into the database. Mocking would make that significantly harder to catch.
Re:How deep are your unit tests? by urbanautomaton on Monday December 10, 2012 @06:29AM (#4898557)
You're quite right, query builder statements are error-prone and difficult to stub; that's why you shouldn't sprinkle them throughout your app. Rather than write things like

  User.active.in_group(x).not_replied.each { ... }
all over the place, write scopes on your User model (e.g. User.awaiting_response_for_group(x)) that represent each use case, test them thoroughly against the database, and then stub them out when testing client code. That way you only have to test the queries in one place, and you don't couple the rest of your code to your query builder.