title: Is it worth testing data access queries themselves?
body: <p>I know that proper SOLID principles combined with IOC mean you can unit test all your code without actually going to the database by mocking out a classes dependencies. My question, following a discussion at work, is whether it's worth actually testing your data access layer itself.</p>
  
  <p>When you've properly separated out your code, your data access method will often be very small. Here's a contrived example:</p>
  
  <pre><code>public class InvoiceQueries
  {
      public IEnumerable&lt;Customer&gt; GetAllCustomersWithOverdueInvoices(TimeSpan timeOverdue)
      {
          var results = 
              from invoice in Invoices
              where invoice.DateDue - timeOverdue &gt; DateTime.Now
              select invoice.Customer;
  
          return results;
      }
  }
  </code></pre>
  
  <p>Is it worth writing an automated test (it wouldn't be a unit test) to check that your query is properly written? Perhaps connect to a real database, or even an in-memory database, insert some test data and then check that your method returns those customers?</p>
  
  <p>One colleague said that you absolutely should - everything should be tested. To me it seems like a huge amount of work to get some form of T-SQL database up and running on the build server, not to mention the fact that these tests will almost certainly be very slow, and of dubious usefulness.</p>
  
  <p>Who has experience actually testing (in an isolated fashion) their data access layer?</p>