C internal access modifier when doing unit testing

Question

I m new to unit testing and I m trying to figure out if I should start using more of internal access modifier  I know that if we use internal and set the assembly variable InternalsVisibleTo  we can test functions that we don t want to declare public from the testing project  This makes me think that I should just always use internal because at least each project  should   have its own testing project  Can you guys tell me why I shouldn t do this  When should I use private

User · Answer

You can use private as well and you can call private methods with reflection. If you're using Visual Studio Team Suite it has some nice functionality that will generate a proxy to call your private methods for you. Here's a code project article that demonstrates how you can do the work yourself to unit test private and protected methods:

http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx

In terms of which access modifier you should use, my general rule of thumb is start with private and escalate as needed. That way you will expose as little of the internal details of your class as are truly needed and it helps keep the implementation details hidden, as they should be.

User · Answer

Internal classes need to be tested and there is an assemby attribute   using System Runtime CompilerServices    assembly InternalsVisibleTo  MyTests      Add this to the project info file  e g  Properties AssemblyInfo cs

User · Answer

Internal classes need to be tested and there is an assemby attribute   using System Runtime CompilerServices    assembly InternalsVisibleTo  MyTests      Add this to the project info file  e g  Properties AssemblyInfo cs

User · Answer

Keep using private by default  If a member shouldn t be exposed beyond that type  it shouldn t be exposed beyond that type  even to within the same project  This keeps things safer and tidier - when you re using the object  it s clearer which methods you re meant to be able to use   Having said that  I think it s reasonable to make naturally-private methods internal for test purposes sometimes  I prefer that to using reflection  which is refactoring-unfriendly   One thing to consider might be a  ForTest  suffix   internal void DoThisForTest string name        DoThis name      private void DoThis string name           Real implementation     Then when you re using the class within the same project  it s obvious  now and in the future  that you shouldn t really be using this method - it s only there for test purposes  This is a bit hacky  and not something I do myself  but it s at least worth consideration

User · Answer

If you want to test private methods  have a look at PrivateObject and PrivateType in the Microsoft VisualStudio TestTools UnitTesting namespace  They offer easy to use wrappers around the necessary reflection code   Docs  PrivateType  PrivateObject  For VS2017  amp  2019  you can find these by downloading the MSTest TestFramework nuget

User · Answer

In  NET Core 2 2  add this line to your Program cs  using     using System Runtime CompilerServices    assembly  InternalsVisibleTo  quot MyAssembly Unit Tests quot     namespace

User · Answer

If you want to test private methods  have a look at PrivateObject and PrivateType in the Microsoft VisualStudio TestTools UnitTesting namespace  They offer easy to use wrappers around the necessary reflection code   Docs  PrivateType  PrivateObject  For VS2017  amp  2019  you can find these by downloading the MSTest TestFramework nuget

User · Answer

If you want to test private methods  have a look at PrivateObject and PrivateType in the Microsoft VisualStudio TestTools UnitTesting namespace  They offer easy to use wrappers around the necessary reflection code   Docs  PrivateType  PrivateObject  For VS2017  amp  2019  you can find these by downloading the MSTest TestFramework nuget

User · Answer

Keep using private by default  If a member shouldn t be exposed beyond that type  it shouldn t be exposed beyond that type  even to within the same project  This keeps things safer and tidier - when you re using the object  it s clearer which methods you re meant to be able to use   Having said that  I think it s reasonable to make naturally-private methods internal for test purposes sometimes  I prefer that to using reflection  which is refactoring-unfriendly   One thing to consider might be a  ForTest  suffix   internal void DoThisForTest string name        DoThis name      private void DoThis string name           Real implementation     Then when you re using the class within the same project  it s obvious  now and in the future  that you shouldn t really be using this method - it s only there for test purposes  This is a bit hacky  and not something I do myself  but it s at least worth consideration

User · Answer

Keep using private by default  If a member shouldn t be exposed beyond that type  it shouldn t be exposed beyond that type  even to within the same project  This keeps things safer and tidier - when you re using the object  it s clearer which methods you re meant to be able to use   Having said that  I think it s reasonable to make naturally-private methods internal for test purposes sometimes  I prefer that to using reflection  which is refactoring-unfriendly   One thing to consider might be a  ForTest  suffix   internal void DoThisForTest string name        DoThis name      private void DoThis string name           Real implementation     Then when you re using the class within the same project  it s obvious  now and in the future  that you shouldn t really be using this method - it s only there for test purposes  This is a bit hacky  and not something I do myself  but it s at least worth consideration

User · Answer

Adding to Eric s answer  you can also configure this in the csproj file    lt ItemGroup gt       lt AssemblyAttribute Include  System Runtime CompilerServices InternalsVisibleTo  gt         lt  Parameter1 gt MyTests lt   Parameter1 gt       lt  AssemblyAttribute gt   lt  ItemGroup gt    Or if you have one test project per project to be tested  you could do something like this in your Directory Build props file    lt ItemGroup gt       lt AssemblyAttribute Include  System Runtime CompilerServices InternalsVisibleTo  gt         lt  Parameter1 gt   MSBuildProjectName  Test lt   Parameter1 gt       lt  AssemblyAttribute gt   lt  ItemGroup gt    See  https   stackoverflow com a 49978185 1678053 Example  https   github com gldraphael evlog blob master Directory Build props L5-L12

User · Answer

You can use private as well and you can call private methods with reflection. If you're using Visual Studio Team Suite it has some nice functionality that will generate a proxy to call your private methods for you. Here's a code project article that demonstrates how you can do the work yourself to unit test private and protected methods:

http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx

In terms of which access modifier you should use, my general rule of thumb is start with private and escalate as needed. That way you will expose as little of the internal details of your class as are truly needed and it helps keep the implementation details hidden, as they should be.

User · Answer

If you want to test private methods  have a look at PrivateObject and PrivateType in the Microsoft VisualStudio TestTools UnitTesting namespace  They offer easy to use wrappers around the necessary reflection code   Docs  PrivateType  PrivateObject  For VS2017  amp  2019  you can find these by downloading the MSTest TestFramework nuget

User · Answer

You can use private as well and you can call private methods with reflection. If you're using Visual Studio Team Suite it has some nice functionality that will generate a proxy to call your private methods for you. Here's a code project article that demonstrates how you can do the work yourself to unit test private and protected methods:

http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx

In terms of which access modifier you should use, my general rule of thumb is start with private and escalate as needed. That way you will expose as little of the internal details of your class as are truly needed and it helps keep the implementation details hidden, as they should be.

User · Answer

I m using  NET Core 3 1 101 and the  csproj additions that worked for me were   lt PropertyGroup gt     lt  -- Explicitly generate Assembly Info -- gt     lt GenerateAssemblyInfo gt true lt  GenerateAssemblyInfo gt   lt  PropertyGroup gt    lt ItemGroup gt     lt AssemblyAttribute Include  quot System Runtime CompilerServices InternalsVisibleToAttribute quot  gt     lt  Parameter1 gt MyProject Tests lt   Parameter1 gt     lt  AssemblyAttribute gt   lt  ItemGroup gt

User · Answer

You can use private as well and you can call private methods with reflection. If you're using Visual Studio Team Suite it has some nice functionality that will generate a proxy to call your private methods for you. Here's a code project article that demonstrates how you can do the work yourself to unit test private and protected methods:

http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx

In terms of which access modifier you should use, my general rule of thumb is start with private and escalate as needed. That way you will expose as little of the internal details of your class as are truly needed and it helps keep the implementation details hidden, as they should be.

User · Answer

Keep using private by default  If a member shouldn t be exposed beyond that type  it shouldn t be exposed beyond that type  even to within the same project  This keeps things safer and tidier - when you re using the object  it s clearer which methods you re meant to be able to use   Having said that  I think it s reasonable to make naturally-private methods internal for test purposes sometimes  I prefer that to using reflection  which is refactoring-unfriendly   One thing to consider might be a  ForTest  suffix   internal void DoThisForTest string name        DoThis name      private void DoThis string name           Real implementation     Then when you re using the class within the same project  it s obvious  now and in the future  that you shouldn t really be using this method - it s only there for test purposes  This is a bit hacky  and not something I do myself  but it s at least worth consideration

User · Answer

Adding to Eric s answer  you can also configure this in the csproj file    lt ItemGroup gt       lt AssemblyAttribute Include  System Runtime CompilerServices InternalsVisibleTo  gt         lt  Parameter1 gt MyTests lt   Parameter1 gt       lt  AssemblyAttribute gt   lt  ItemGroup gt    Or if you have one test project per project to be tested  you could do something like this in your Directory Build props file    lt ItemGroup gt       lt AssemblyAttribute Include  System Runtime CompilerServices InternalsVisibleTo  gt         lt  Parameter1 gt   MSBuildProjectName  Test lt   Parameter1 gt       lt  AssemblyAttribute gt   lt  ItemGroup gt    See  https   stackoverflow com a 49978185 1678053 Example  https   github com gldraphael evlog blob master Directory Build props L5-L12

User · Answer

In  NET Core 2 2  add this line to your Program cs  using     using System Runtime CompilerServices    assembly  InternalsVisibleTo  quot MyAssembly Unit Tests quot     namespace

User · Answer

I m using  NET Core 3 1 101 and the  csproj additions that worked for me were   lt PropertyGroup gt     lt  -- Explicitly generate Assembly Info -- gt     lt GenerateAssemblyInfo gt true lt  GenerateAssemblyInfo gt   lt  PropertyGroup gt    lt ItemGroup gt     lt AssemblyAttribute Include  quot System Runtime CompilerServices InternalsVisibleToAttribute quot  gt     lt  Parameter1 gt MyProject Tests lt   Parameter1 gt     lt  AssemblyAttribute gt   lt  ItemGroup gt

[c#] C# "internal" access modifier when doing unit testing

Examples related to c#

Examples related to .net

Examples related to unit-testing

Examples related to tdd