{"id":1383,"date":"2024-12-08T00:00:00","date_gmt":"2024-12-07T23:00:00","guid":{"rendered":"https:\/\/demo.sidekick.be\/itenium\/testing-internals\/"},"modified":"2025-11-28T13:31:41","modified_gmt":"2025-11-28T12:31:41","slug":"testing-internals","status":"publish","type":"post","link":"https:\/\/demo.sidekick.be\/itenium\/blog\/dotnet\/testing-internals\/","title":{"rendered":"Testing Internal Methods"},"content":{"rendered":"

The tests are your safety net you want to rely on!<\/p>\n

When<\/h1>\n

There are actually many cases where you want to do this:<\/p>\n

Legacy Singletons<\/h2>\n
\n

The Legacy Code Dilemma<\/strong>
When we have to change code, we should have tests in place.
To put tests in place, we often have to change code.<\/p>\n<\/blockquote>\n

Your old legacy codebase has something like:
(yeah, it\u2019s probably a lot more convoluted than this)<\/p>\n

public class Singleton\n{\n  public static readonly Singleton Instance = new();\n  private Singleton() { }\n}\n<\/code><\/pre>\n
Refactored Testable Singleton<\/h3>\n
We introduce an interface, mimicking the original API and provide an internal<\/code> setter so that we can substitute it with something else during testing!<\/p>\n
public class Singleton : ISingleton\n{\n  private static ISingleton _instance = new Singleton();\n\n  public static ISingleton Instance\n  {\n    get => _instance;\n    \/\/ We introduced a \"seam\"!\n    internal set => _instance = value;\n  }\n\n  private Singleton() {}\n}\n<\/code><\/pre>\n
Limiting the API surface<\/h2>\n
Inside project X you have some helper classes\/functions, a few Extension Methods, or maybe part of your startup code has some logic in it.<\/p>\n
These are all internal<\/code> because you like your projects to have a clean public API, exposing only those things that external users are interested in, and hide everything else.<\/p>\n
You don\u2019t want to make them public, but obviously you do want to write tests for them!<\/p>\n
When Not<\/h2>\n
public class Calculator\n{\n  public Result Calculate()\n  {\n    var step1 = Step1();\n    var step2 = Step2(step1);\n    return Step3(step2);\n  }\n\n  internal object Step1() {}\n  internal object Step2(object data) {}\n  internal Result Step3(object data) {}\n}\n<\/code><\/pre>\n
I\u2019ve seen code like this. Instead of testing the public Calculate<\/code> method only, there are also UnitTests for the sub-algorithms, methods which have been made internal<\/code> only for those UnitTests.
 Maybe even mock out the Step1-3<\/code> when testing the public method \ud83d\ude32<\/p>\n
It\u2019s almost always a bad idea; as your implementation and your tests are now very strongly tied together. It\u2019s become hard to change the sub-parts. Worse, if the requirements change, Step1-3<\/code> might not make much sense anymore but you\u2019re probably going to endure anyway rather than rewrite all those tests\u2026<\/p>\n
How<\/h1>\n
This blog post was supposed to be just this but, well, I got carried away\u2026<\/p>\n
Old Legacy Project Format<\/h2>\n
Create an AssemblyInfo.cs<\/code> class and add:<\/p>\n
using System.Runtime.CompilerServices;\n[assembly: InternalsVisibleTo(\"Company.Project.UnitTests\")]\n<\/code><\/pre>\n
New SDK-Style Project Format<\/h2>\n
Add to the csproj<\/code> file:<\/p>\n
<ItemGroup>\n  <AssemblyAttribute Include=\"System.Runtime.CompilerServices.InternalsVisibleTo\">\n    <_Parameter1>Company.Project.UnitTests<\/_Parameter1>\n  <\/AssemblyAttribute>\n<\/ItemGroup>\n<\/code><\/pre>\n
Summary<\/h1>\n
I could easily remember the AssemblyInfo<\/code> version but the csproj<\/code> one\u2026 not so much.<\/p>\n
Ready for copy-pasta now!<\/p>\n
Somehow I ended up writing about \u201chigh cohesion\u201d, \u201cWorking Effectively with Legacy Code\u201d and \u201cencapsulation\u201d instead!<\/p>\n
Extras<\/h1>\n
Stuff that came into being during the making of this post<\/b><\/p>\n