ansaurus

Question

How to use web.config when unit testing an asp .net application

Answer 1

+5 A:

Unit test projects should have their own config file.

On a test project you can choose Add, New Item, Application Configuration File.

This file will behave exactly like a web.config, but then for your unit tests.

Gerrie Schenck 2009-02-05 15:02:19

I've tried what you suggested, I added a new config file into my test project. The connection string is in place, but when running my tests I always see null on the line var sqlCon = new SqlConnection(ConfigurationManager.ConnectionStrings["SqlServer"].ConnectionString); What might I be missing?

ilivewithian 2009-02-05 15:48:07

you added web.config file?

Marko 2010-07-07 08:28:12

Answer 2

+3 A:

You will want your results to be well-defined and repeatable. To to this, you'll need to be working against known data so that you can clearly define both your normal cases and your boundary cases. In my work, this is always a specific server and dataset so the Unit testing module has the connection string built in. Others prefer using a connection string out of the Unit Testing project. I've never seen anyone recommend the use of the web site's config file! (development or otherwise)

Mark Brittingham 2009-02-05 15:07:01

That makes a lot of sense, so what's the solution to getting the connection strings into my app for testing?

ilivewithian 2009-02-05 15:44:09

Either hard code the Connection String that is *specific to your testing environment* (this has a bad smell but it is really quite practical as it has nothing to do with deployable code) or use a Config file defined specifically for your unit testing module as Gerrie suggested.

Mark Brittingham 2009-02-05 20:54:12

Just to emphasize: I am not suggesting that you *ever* hard code a database connection string in code that will be deployed! I have a specific database on a specific server that I always use for unit testing. Before testing, I run a script that ensures that the db is in the appropriate state.

Mark Brittingham 2009-02-05 20:59:31

Answer 3

A:

If you need a connection string, you are not writing a unit test (assuming that you are using the connection string for going to database). Unit tests are not supposed to interact with outside environment. You will want to run all of them after each check in so they better run at the speed of light.

For a unit test, you will want to isolate your code from your database. Modify your tests (and the code you are testing if necessary) so that you will not need to go to database for testing them.

Serhat Özgel 2009-02-05 15:38:02

So are you suggesting that I don't test any code that accesses a database?

ilivewithian 2009-02-05 15:42:57

he's suggesting you don't test it against the database defined in your web.config

annakata 2009-02-05 15:45:00

No. Your code must *never* access to the database (unless you are writing a database framework). Instead, you pass an object to your code, which accesses to database. In your unit tests, you mock that object, in production, you use the actual database accessing class.

Serhat Özgel 2009-02-05 15:49:59

buyutec is right, when you this your tests aren't unit tests anymore, but integration tests.

Gerrie Schenck 2009-02-05 15:52:31

I just flat out disagree with this on a fundamental level. It takes Unit Testing out of the realm of practical, hands-on tool for improving your code, and turns it into an abstraction hemmed in by artificial boundaries.

Mark Brittingham 2009-02-05 20:52:30

If you cannot run all your unit tests after each check in because you have to go to database a few hundred times, that would be impractical.

Serhat Özgel 2009-02-06 07:51:49

But the code has to access a database, so you have to test that functionality - using a test database created for the purpose - and that test database needs a connection string.

finnw 2009-02-06 12:46:32

Database functionality can be tested with integration tests, not unit tests. And you can separate these from your unit tests so you run unit tests after each check in and your integration tests after each daily build or whenever you want.

Serhat Özgel 2009-02-06 12:53:15

Ok, so I get why you would want to seperate unit test and integration tests. So if I run my unit tests before each code checkin, how often should I run my integration tests? I oftern find that I make a change on the database at the same time as I change code.

ilivewithian 2009-02-06 14:34:29

My answer would be as often as possible. "After each daily build" sounds reasonable but it may change depending on your project needs. In addition to daily builds, you may run them whenever you are uncomfortable with your changes.

Serhat Özgel 2009-02-06 15:50:18

Why would "having to go to the database a few hundred times" prevent you from checking in? We may just have different methods as well. I run unit tests before checking in and typically check in and build together. Then again, I'm a solo developer. Still, this seems artificially limited to me.

Mark Brittingham 2009-02-08 13:02:46

i think that ilivewithian wants to know how to setup test project so he can properly test methods that access database...and for me it is little strange that you have to put the same web.config in test project(doesn't matter it is integration or unit test) so you could do that...what do you think?

Marko 2010-07-07 08:26:18

ansaurus

tags:

views:

answers:

How to use web.config when unit testing an asp .net application

related questions