Модификатор internal в C# и модульное тестирование: как протестировать внутренние методы?

Использование InternalsVisibleTo для тестирования internal-методов

Проблема, с которой вы столкнулись, очень распространена. Модификатор internal ограничивает доступ к типу или члену класса только в пределах той же сборки. По умолчанию тестовый проект — это отдельная сборка, поэтому он не видит internal-члены.

Решение — атрибут InternalsVisibleTo. Он позволяет указать, какой сборке (тестовому проекту) предоставить доступ к internal-членам вашей основной сборки. Это стандартный и рекомендуемый способ для unit-тестирования.

Как это настроить

Есть два способа добавить атрибут:

1. Через файл проекта (.csproj) — современный и предпочтительный способ.
2. Через файл AssemblyInfo.cs — классический способ.

Способ 1: Через .csproj (рекомендуется)

Откройте файл проекта MyLibrary.csproj и добавьте в первый следующий элемент:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <InternalsVisibleTo>MyLibrary.Tests</InternalsVisibleTo>
  </PropertyGroup>
</Project>

Если тестовый проект имеет строгое имя (strong name), нужно указать полный публичный ключ:

<InternalsVisibleTo>MyLibrary.Tests, PublicKey=0024000004800000940000000602000000240000525341310004000001000100...</InternalsVisibleTo>

Способ 2: Через AssemblyInfo.cs

Добавьте файл AssemblyInfo.cs в корень проекта MyLibrary:

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("MyLibrary.Tests")]

После этого в тестовом проекте вы сможете обращаться к internal-типам и методам:

// В тестовом проекте MyLibrary.Tests
using MyLibrary;

[TestClass]
public class InternalServiceTests
{
    [TestMethod]
    public void GetSecretData_ReturnsCorrectString()
    {
        // Arrange
        var service = new InternalService();
        
        // Act
        var result = service.GetSecretData();
        
        // Assert
        Assert.AreEqual("SensitiveInfo", result);
    }
}

Нарушает ли это инкапсуляцию?

Короткий ответ: нет, если использовать правильно. InternalsVisibleTo — это осознанное решение разработчика открыть internal-члены для тестов. Вы по-прежнему контролируете, какие типы видны внешним сборкам (через public), а какие — только тестам.

Рекомендации по best practices:

• Тестируйте через публичный API в первую очередь. Если метод GetSecretData() используется только внутри ProcessData(), тестируйте через ProcessData().
• Используйте InternalsVisibleTo только для сложной внутренней логики, которую невозможно протестировать косвенно (например, алгоритмы, парсеры, валидаторы).
• Не злоупотребляйте. Если вы тестируете каждый private-метод через рефлексию или делаете всё internal — это плохой дизайн.
• Документируйте. Добавьте комментарий в AssemblyInfo.cs о том, зачем вы открываете доступ тестам.

Также есть альтернатива — вынести сложную логику в отдельный публичный класс (например, ISecretDataProvider), но это может быть избыточно для простых случаев.

// Определяем публичный интерфейс
public interface IDataProcessor
{
    string ProcessData();
}

// Внутренняя реализация остается internal
internal class InternalService : IDataProcessor
{
    public string GetSecretData() => "SensitiveInfo";
    
    public string ProcessData() => GetSecretData().ToUpper();
}

// Публичный класс использует DI
public class PublicService
{
    private readonly IDataProcessor _processor;
    
    public PublicService(IDataProcessor processor)
    {
        _processor = processor;
    }
    
    public string ProcessData() => _processor.ProcessData();
}