Integration testing and database connection string in app.config

Question

I am working on a project where SqlConnection is created via a static method, lets say it's DatabaseAccess.GetSqlConnection(). This method reads the .config file to get the connection string and creates a connection.

Is it ok to refactor the code to use an ISqlConnectionCreator (or ISqlConnectionFactory) responsible for creating the actual connections just for the sake of testing (as it seems more "by the book" for me) or go easy and just create a .config file in the test project containing test connection strings?

The second solution seems more error-prone and creates an indirect relation between tests and the tested classes.

I want to make sure there is a justification for the extra work of refactoring code to use the injected connection creator.

• Al.exe: Disclaimer, I work at Typemock. I agree with Doc Brown on use what works best and requires less maintenance. You can use mocking to avoid refactoring altogether from your production code. Just mock the static DatabaseAccess.GetSqlConnection() method.
• gnat: This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post.
• user1713059: Maybe I misunderstood something, but I generally like this idea - it might save me the refactoring bit and I will still be able to control the connection string used... but I don't know if there is a free static-mocking tool, that might be important for my company.
• Al.exe: There are no free static mocking tools.
• Al.exe: In that case you'll have to do some refactoring after all. You can extract only the code that retrieves the connection string from the .config file to a method, then extract an interface from this method, and mock it with a free mocking framework.

Answer 1

From a pragmatic view I would recommend to use whatever works best, with the least maintenance effort.

In this specific situation, I would probably go with "option 3": separate the part which reads the connection string from the part which creates the actual connection into two different methods. So the connection string becomes an input parameter of method 2, and in your test code, you can omit the config evaluation and provide the test connection string any way you like, for example, as part of the hardcoded test data. As a result, you do neither need a test config file, nor an ISqlConnectionCreator.

• user1713059: I'm not sure if I understand correctly, but i think you propose to add a string connectionString parameter to the DatabaseAccess.GetSqlConnection(). If so, the code will need versy similar amount of work to be refactored (as with the connection factory), don't you think?
• user1713059: Yeah I think I misunderstood, but anyway you propose to pass connection string to all database methods, right?

Answer 2

I'm having a hard time seeing the benefit from this extra code. Code is a liability and unless there is an actual problem I probably wouldn't want to spend time on it.

I would just create the app.config file and call it a day.

• RubberDuck: Never mind good, decoupled design then, right?
• Esben Skov Pedersen: never mind kiss and yagni. it is all a balance and an analysis of the current project instead of automatic reactions for more complexity.