Модульное тестирование: частные методы и методы рефакторинга

Question

Мне нравится модульное тестирование, оно доказывает свою ценность в течение последних полутора лет, или около того, когда я его использовал.Тем не менее, у меня всегда есть проблема или, скорее, проблема с закрытыми методами (и защищенными).

Я не хочу делать их общедоступными или использовать внутренние компоненты, видимые для атрибута.Мне нужно чистое и четкое решение - это тестируемое, и я с гордостью позволю кому-то еще взглянуть на него.

Я прихожу к выводу, что если частный метод действительно нуждается в тестированииНезависимо от этого, возможно, его следует перенести на другой интерфейс и использовать ассоциацию для предоставления функциональности вызывающему методу.Я считаю, что это, по сути, шаблон Фасада.

Действительно ли это лучший способ сделать это?Или более объективно ... есть ли другие подходы, которые я полностью упустил из виду?

Редактировать: Мы говорим о конкретном языке?Я работаю в C #.Я держал код вне вопроса, когда искал что-то абстрактное.Возвращаясь к этому сегодня, я понимаю, что, возможно, это глупость из-за того, что языки действительно отличаются друг от друга.

Так что некоторый код:

public class CopmlexClass
{
    public void SomeMethod()
    { }

    private void workerMethod()
    { }
}

будет преобразован в

public class CopmlexClass
{
    public void SomeMethod()
    { }

    public IComplexClassWorker Worker { get; set; }

}

public interface IComplexClassWorker
{
    void WorkerMethod();        
}

На самом деле id, вероятно, предпочитают использовать инжектор конструктора и даже не выставлять свойство

Мой вопрос: это лучший способ?Какие альтернативные отражения / внутренние элементы видимы для атрибута?

Answer 1

Закрытый метод, который необходимо протестировать независимо, может быть результатом следующего:

• ваш класс делает слишком много - его открытые методы реализуют функциональность, которая слишком сложна, чтобы ее можно было протестировать какцелое и / или
• эффекты вызова конкретного частного метода не могут быть непосредственно восприняты извне класса.

Оба случая обычно являются явным вызовом для извлечения другогокласс, содержащий некоторые частные методы исходного класса, превращенный в открытый, что делает его непосредственно тестируемым.(Иногда сложной задачей является поиск логически сплоченных кусочков функциональности, которые могут самостоятельно образовывать полезные классы. Сначала вы не всегда можете получить идеальный результат - при рефакторинге иногда нужно идти на компромисс, небольшой шаг в некоторыхпока еще не определено четко направление. В долгосрочной перспективе такой шаг может открыть новые возможности, привлечь внимание к другим подобным частям кода, или новый класс может начать привлекать биты кода из других мест, в конечном итоге формируя согласованный классИли превращение во что-то совершенно новое, но лучше, чем вы изначально представляли.)

Представление частного метода через другой интерфейс / фасад - это то, что IMO не решит проблему в долгосрочной перспективе, а только запутает воду.Классы должны иметь четко определенный, полный и минимальный интерфейс.Разоблачение приватных методов любым способом может открыть способы поставить под угрозу внутреннее состояние объекта, что является плохой вещью.

Answer 2

Когда мы начали писать модульные тесты в нашей команде пару лет назад, мы начали с правил, которые вы изложили выше, то есть мы тестировали открытый интерфейс сборки.

Мы ожидали, что одно преимущество будет вобнаружение недоступного кода.Если инструменты покрытия кода обнаруживают блоки кода, которые не тестируются, то либо тесты отсутствуют, либо код недоступен и должен быть удален.

Но на практике мы не придерживались их.У нас очень модульный дизайн - более 30 проектов в нашем основном решении (большинство из которых имеют соответствующий проект модульных тестов).Теперь мы обычно предоставляем тестовому проекту доступ к внутренностям тестируемого проекта.

Я думаю, что одной из проблем является то, что мы не используем автоматически покрытие кода для обнаружения пропущенных тестов или недоступного кода.Поскольку это ручной процесс, он не выполняется.