Unit tests and database

The first one shouldn't be that hard if you've got a Data Access Layer that exposes just a handful of IQueryable<T> methods. There's a nice trick you can use for fake data: just store the entity objects in a List<T> and use AsQueryable. I find this easier than moq for the data parts.\n\nRegarding IOC, I take the position that it's currently overused (be aware that my opinion represents the minority of programmers in this regard). You can use a tool like Moles during testing to mock without having to abuse your program's design. I don't use IOC unless the design actually calls for it.",

I would definitely continue to use true unit tests (option 1). I like Stephen's advice for this.\n\nYou may also find integration tests with an actual database (option 2) necessary to use as well (option 2). Why? Because part of what you need to test (O/R mapping, compatability with the actual DB schema, etc.) are not covered by true unit tests.\n\nAs for setup and teardown logic, inheriting from this usually suffices (using .NET, NUnit, and SqlServer for the database):\n\nusing System.Transactions;\nusing NUnit.Framework;\nnamespace Crown.Util.TestUtil\n{\n [TestFixture]\n public class PersistenceTestFixture\n {\n public TransactionScope TxScope { get; private set; }\n\n [SetUp]\n public void SetUp()\n {\n TxScope = new TransactionScope();\n }\n\n [TearDown]\n public void TearDown()\n {\n if (TxScope != null)\n {\n TxScope.Dispose();\n TxScope = null;\n }\n }\n }\n}\n\n\nEasy as pie.",

There's a whole suite of answer to this. The first thing to do is to clearly articulate what you are testing. Is it the facade of an API that has a database behind it, DAO objects, your database structure? \n\nGetting to this will also help you decide the best way to test things. There is also from what I can see an alternative to the ones you list. That is to start up in in memory database such as hsql and run your classes and tests against that. This means that you can create the database structure at the start of you tests. Because it's in memory you don't have to worry about having a database server, it's fast, and you can load it with data specific to your test. \n\nI use mocks quite a bit and whilst they are great for unit testing a class, in some cases they are not. They can also miss lead quite easily. It's not uncommon for something that works with mocks, to not work when integrated. The reasonnfor this is that you are loading the mock with certain expectations and responses, which you may have wrongly intepreted from the thing that the mock represents.\n\nDon't get me wrong, I like mocks and use them quite a bit. But in doing so you must never assume that because something is unit tested, it's correct. It does increases the chances, but on integration tests actually give you 100% assurance.",