1

I am currently working on a C# solution in VS 2010.

In order to write sufficient unit tests for my business processes I am using the Accessor approach to access and change the internals of my business objects.

The issues that has arisen on my TFS build server now that I have added Accessors to my objet assembly in a number of other test assemblies, when my test run not all the test pass, some fail with a warning along the lines of:

... <Test failed message> ....
... Could not load file 'ObjectLibrary_Accessor, Version=0.0.0.0, 
        Culture=neutralm PublicKeyToken=ab391acd9394' or one of its dependencies.
...
...

I believe the issue is that as each test assembly is compiled a ObjectLibrary_Accessor.dll is created with a different strong name. Therefore when some of the tests are compiled the strong name check fails with the above error even-though the dll is in the expected location.

I see a number of options, none of which are particularly attractive, these include:

  1. Not using the _Accessor approach.
  2. Set a different XX_Accessor.dll for each test assembly - Is it possible to change the name of the generated assembly to avoid the clash?
  3. Change my integration build to use a different binaries folder for each test project(how?)
  4. Other options I do not know about?

I would be interested in any advice or experience people have had of this issue, solutions and workarounds (although I do not have time to change my code so option 1 is not a favorate).

Chris J
  • 30,688
  • 6
  • 69
  • 111
user935653
  • 143
  • 7

1 Answers1

3

The Accessor approach is a bit fragile, as you've seen.

You can make internal items visible to your test code by using the InternalsVisibleTo assembly attribute.

If you want to get at private methods and you're using .NET 4.0 then consider using something like Trespasser to make this easier.

For more options see the answers for this question: How do you unit test private methods?

Community
  • 1
  • 1
Richard Banks
  • 12,456
  • 3
  • 46
  • 62