Databases
StackOverflow2013
Postsdbo
POInternalsVisibleTo seems ignored
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POInternalsVisibleTo seems ignored
    primarykey
    data
    text
    <p>I'm trying to unit test a private function in .net. This private function returns a collection of type <code>myClass</code>, which is an internal class. </p> <p>I've used the assembly attribute <code>InternalsVisibleTo</code>, so that the type <code>myClass</code> is known to my Test project.</p> <p>Here's the code I want to test:</p> <pre><code>namespace MyProject { public class Class1 { private List&lt;myClass&gt; myFunction() { return new List&lt;myClass&gt;(); } internal class myClass { public int MyProperty { get; set; } } } } [TestMethod()] [DeploymentItem("MyProject.dll")] public void myFunctionTest() { Class1_Accessor target = new Class1_Accessor(); List&lt;Class1_Accessor.myClass&gt; expected = null; List&lt;Class1_Accessor.myClass&gt; actual; actual = target.myFunction(); Assert.AreEqual(expected, actual); Assert.Inconclusive("Verify the correctness of this test method."); } </code></pre> <p>and in my assembly info file:</p> <pre><code>[assembly: InternalsVisibleTo("MyProject.Test")] </code></pre> <p>So why does Visual Studio set the type of the list to <code>Class1_Accessor.myClass</code> since <code>myClass</code> is known to my test project ? </p> <p>Because of that I get a runtime error (cannot convert type <code>myClass</code> to type <code>Class1_Accessor.myClass</code>).</p> <p>Because myFunction is private, VisualStudio generates the following code (which is fine for most of it)</p> <pre><code>[Shadowing("MyProject.Class1")] public class Class1_Accessor : BaseShadow { protected static PrivateType m_privateType; [Shadowing(".ctor@0")] public Class1_Accessor(); public Class1_Accessor(PrivateObject value); public static PrivateType ShadowedType { get; } public static Class1_Accessor AttachShadow(object value); [Shadowing("myFunction@0")] public List&lt;Class1_Accessor.myClass&gt; myFunction(); [Shadowing("MyProject.Class1+myClass")] public class myClass : BaseShadow { protected static PrivateType m_privateType; [Shadowing(".ctor@0")] public myClass(); public myClass(PrivateObject value); [Shadowing("MyProperty")] public int MyProperty { get; set; } public static PrivateType ShadowedType { get; } public static Class1_Accessor.myClass AttachShadow(object value); } } </code></pre> <p>However, I don't understand why it contains a new definition of myClass, since it is an internal class, which shouldn't need any accessor. This is the root of the problem in my opinion.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USSam
    1. USSam
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POInternalsVisibleTo seems ignored
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POInternalsVisibleTo seems ignored
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POInternalsVisibleTo seems ignored
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYou might want to add the `mstest` tag to attract the attention of those who are experienced with using Accessors. I wasn't sure which tag to delete, so I didn't edit the tags myself. I never much cared for accessors, so I have little experience. (Further, there's a strong sentiment that you shouldn't be testing private members; if you have a private member that's not indirectly testable through a public one, then it's a sign that you should extract a separate class for that logic.)
      singulars
      1. POInternalsVisibleTo seems ignored
      1. USphoog
    2. COthanks, I've added the tag. Testing private members or not is a whole different topic (although you are right). Nevertheless, I still want to test that one function.
      singulars
      1. POInternalsVisibleTo seems ignored
      1. USSam
    3. CORegarding the testing of private members, the fact that it's a whole different topic is the reason I put that in parentheses. And of course there are always defensible exceptions to guidelines like that. I'd add that when I *have* tested private members I've generally just used reflection -- I even have some helper methods for the purpose (e.g., `CallNonPublicMethod(string methodName)`). I find that easier to deal with than the accessors -- I never figured out how to get them regenerated when I modified the classes they were shadowing.
      singulars
      1. POInternalsVisibleTo seems ignored
      1. USphoog
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload