2

In Visual Studio, I have a unit test that calls a method on a class in another project - let's call it MyClass.A().

Inside A(), it accesses a setting in MyClass' project properties.

When I use MyClass.A() during normal runtime, it gets the correct value from the setting. However, when I do it from the unit test, it returns null. Do I need a post-build event in the unit test project to copy the settings over?

This is how the settings are being accessed in MyClass.A():

string connectionString = global::DataAccess.Properties.Settings.Default.ConnectionString;

RESOLUTION

So the issue had to do with the moldering pile of wet toilet paper I like to call my brain. There is a public property on MyClass that I needed to set with the connection string. The Set accessor assigns the value to the appropriate Settings property. Thanks for all the responses.

lintmouse
  • 5,079
  • 8
  • 38
  • 54
  • I realize that what I'm doing is not technically unit testing, so I should've given this post another title. Ultimately, I would just like to find out why it is not getting the correct Setting value when run from a unit test... – lintmouse Nov 27 '12 at 19:22

2 Answers2

2

You actually have 2 options, firstly you could make the Settings Public instead of Internal.

Secondly, you can add the InternalsVisibleToAttribute to the main assembly specifying the Unit Test assembly.

[assembly:InternalsVisibleTo("MyUnitTestLibrary")]

On a side note, you should store the connection string in the app.config using ConnectionStringsSection and use ConfigurationManager to read it.

Trevor Pilley
  • 16,156
  • 5
  • 44
  • 60
  • I made the settings public (in Settings.Designer.cs), but it is still returning a null value. The code that is accessing the settings is inside the same project as the settings. Would I still need to make them public then? – lintmouse Nov 27 '12 at 16:29
2

If you're accessing a connection string this doesn't actually seem like a Unit Test. You may be better off mocking whatever behavior relies on the connection string so you can isolate your functionality. Take a look at some of the test frameworks here (I'm patial to Moq).

Chris
  • 2,885
  • 18
  • 25
  • I am writing a service that utilitzes a pretty industrious chunk of existing code to validate incoming data. The connection string is in the validation code. It checks for duplicates in the target database. I know that it isn't pure unit testing, but I'd rather not have to mock up that part of the code if I can avoid it. I haven't checked out Moq yet, but I'll look into it. I've used NUnit and it seemed pretty good. – lintmouse Nov 27 '12 at 16:32
  • So are you actually testing the validation logic to search for duplicates? Also, what's the output you get from this validation code? – Chris Nov 27 '12 at 16:51
  • The validation logic has been in use for a while with an existing app. It returns a bool value if it passed or not. I think I understand what you're getting at. It would be very easy to mock the validation or just bypass it completely in the unit test. But because the validation logic is very complex/convoluted, I want to test it to make sure that I understand what state the data needs to be in to pass. – lintmouse Nov 27 '12 at 17:34
  • 1
    @smudgedlens, it sounds like you really, really need to perform an Extract Method refactoring. Pull the validation logic out into a separate method. Then you can exercise unit tests against that method without needing the socket at all. – John Deters Nov 27 '12 at 18:48
  • The issue here is that it would be outside the scope of my current project to do that. I understand that what I'm doing is not ideal, but I would like to test just the service and not tinker with the validation code. – lintmouse Nov 27 '12 at 19:18