A few things here ... Firstly parameterizing the connection string as already suggested by a few is the right way to go. You say you don't want "a code change" only for your unit tests. Well a connection string change shouldn't be a code change in the first place so this seems like it will work out well for you.
Secondly, the unit tests have a funny smell around them. It is generally considerred bad practice to have unit tests hitting a database for a few reasons although I think what might be happenning is a difference in terms in that you are really meaning to say "integration tests". Generally speaking when dealing with unit tests one removes the SQL db from the equation (or at the least uses a different SQL db such as SQLite as opposed to their normal db say SQL Server). This is done because there are many things not related to your code that could feasably make your unit tests fail when dealing with a networked database and dealing with the networked database will be unnecesarily slow (causing your code/test loop to take much more time thus lowerring developer productivity. Cheers, Greg On 2/16/07, Andy Smith <[EMAIL PROTECTED]> wrote:
Hi - I'm working with unit tests, and for a particular reason (won't bore you with the details, has to do with timing issues when killing connections during tests), I'd like to disable connection pooling for the entire process that the unit tests will run under. I know it's possible to set Pooling=false in the connection string, but that would entail a change to code that I'd rather avoid, since it only applies to when a unit test is running. Anyone know if it's possible to disable connection pooling for an entire process? Thanks! Andy =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
-- Studying for the Turing test =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
