1

I am trying to proceed with my Entity Framework + testing experience. I wrote tests in NUnit that delete the tables, create a fresh database, create rows in tables required for testing, do the tests, and repeat.

There is a nice post about two different test strategies that explain that there are some downsides to testing with Effort (in memory database). I did have a strong preference for testing against an actual database anyway, because then I can verify the real database to verify if and how things end up in the database.

Then I came across this post, where I can read that I should/could have a different database server for my application and for my tests. E.g. application runs against SQL Server, while tests run against SQL Server CE.

I have a couple of working integration tests now that work on SQL Server Express. My application runs on the same connection string, against the same database server instance.

Is that unwise?

Am I in trouble on the long run?

Can anybody confirm and explain if it is required / advised to use a different database server for the application (SQL Server) and the integration tests (SQL Server CE)?

Thanks a lot in advance.

Community
  • 1
  • 1
bas
  • 13,550
  • 20
  • 69
  • 146
  • I visited the post that says that you should/could have a different database server, but didn't actually find on that post anything that says "you should have two different database servers". – Mark Hildreth Feb 24 '13 at 09:23
  • @MarkHildreth, you are right, I will rephrase the question "can anybody confirm and explain IF it required / advised to use a different database server ..." (why => if). Can I draw to an early conclusion that you think it's not needed and that I can just use the same server for both the application and the test environment? – bas Feb 24 '13 at 09:30
  • I assume by "same server", you mean "same server type" (MSSQL is one type of server, SQL CE is another, sqlite another..). Obviously, you don't want to use your live server (the actual server with all your live data) as your test server, as you will end up putting a bunch of test data into your live server, or completely wiping out your live data... – Mark Hildreth Feb 24 '13 at 09:33
  • @MarkHildreth I can at least conclude that it's hard to ask the question with enough details so that you lot can help me further :). But again, you are right. It's on my development server, not the actual customer server. Application and test environment use the same database server type, same scheme, different name ('Test_databasename'). – bas Feb 24 '13 at 09:35

1 Answers1

7

It might be worthwhile to use SQL Server as your database, and SQL Server CE as your test database. This is common, as it might be faster to run your tests on SQL Server CE rather than SQL Server for the things that these tests typically do (create an entire datatabase, do a quick transaction, then completely destroy it). It also means you don't need to have a full SQL Server installation on your development machine.

However, there isn't a NEED to do this. Some might also not want to do this. You might even be using a feature in your program that is only available on SQL Server, which basically means you would not be able to use SQL Server CE.

Finally, there is the possibility that your code works with SQL Server CE, but not with SQL Server, and therefore problems are not brought up during testing. At one point, I ran an app against MySQL, but used sqlite for running some tests. There was a slight difference in how sqlite worked versus MySQL which caused my program to work fine in tests, but fail in live.

So, I would still recommend being able to test against the same type of database that you'll use in live. You can always find middle ground, such as developing against a SQL Server CE test database, and then switch over to testing on SQL Server just before going live with a new version to cover that case as well.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Mark Hildreth
  • 42,023
  • 11
  • 120
  • 109
  • In one word: awesome. Thanks a lot! One thing less to worry about. It gives comfort in my head knowing that I am not doing something I'll regret later. +1 – bas Feb 24 '13 at 09:44