Как к закрытым методам модульного теста в BDD / TDD?

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

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

Краткий ответ: Вы не тестируете частные методы.

Если вы хорошо запрограммировали, покрытие кода ваших тестов должно включать неявное тестирование частных методов.

Если существует метод частного метода, он будет использоваться публичным методом. Поэтому я бы написал тест для общедоступного метода.

Я пишу свои тесты для тестирования общедоступных частей класса. Если класс хорошо спроектирован, частные части тестируются по умолчанию.

Если частный метод не вызывается из общедоступного метода, то почему он существует?

В вашем случае я бы сделал следующее

* Write failing test for the public method
* Write public method that calls the private method that doesn't exist yet(test still fails as your class is incomplete
* Write the private method
* Test should now pass

Mbunit Reflector поможет вам в этом.

Reflector objectReflection = new Reflector(new ObjectWithprivateMethods());
objectReflection.InvokeMethod(AccessModifier.NonPublic,,"Add",1,6));

Сообщение об этом в блоге.

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

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

public class TestableClassToTest : ClassToTest
{
    public new void MethodToTest() 
    { 
        base.MethodToTest(); 
    } 
}

. Возможно, вы уже используете этот шаблон Extract and Override , чтобы переопределить виртуальные свойства базового класса для внедрения зависимостей, в этом случае это может быть для вас жизнеспособным вариантом.

Краткий ответ : Вы не можете протестировать частный метод.

Длинный ответ : Вы не можете протестировать частный метод, но если вы склонны протестируйте все, что он считает рефакторингом вашего кода. Существует два тривиальных подхода:

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

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

Надуманный ответ : Хорошо, я солгал. Вы можете протестировать частный метод с помощью некоторой магии отражения (некоторые инструменты TDD поддерживают тестирование частных методов). По моему опыту, это приводит к запутанным модульным тестам. Запутанные модульные тесты приводят к худшему коду. Худший код приводит к гневу. Гнев ведет к ненависти. Ненависть приводит к страданиям …

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

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

Запутанные модульные тесты приводят к худшему коду. Худший код приводит к гневу. Гнев ведет к ненависти. Ненависть приводит к страданиям …

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

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

Запутанные модульные тесты приводят к худшему коду. Худший код приводит к гневу. Гнев ведет к ненависти. Ненависть приводит к страданиям …

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

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

Гнев ведет к ненависти. Ненависть приводит к страданиям …

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

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

Гнев ведет к ненависти. Ненависть приводит к страданиям …

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

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

Ненависть приводит к страданиям …

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

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

Ненависть приводит к страданиям …

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

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

Это противоречит цели TDD, то есть сделать производственный код тестируемым, расширяемым и, что более важно, повторно используемым.

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

Это противоречит цели TDD, то есть сделать производственный код тестируемым, расширяемым и, что более важно, повторно используемым.

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

Вы должны тестировать только внешний API ваших классов, то есть общедоступные методы. Если ваши тесты не затрагивают код в частных методах, то вам нужно либо написать больше тестов, либо провести рефакторинг класса.

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

Как вы определили, здесь BDD вступает в игру по сравнению с «традиционным» TDD используя фиктивные классы, где каждый вызов метода должен быть настроен заранее для теста. Я не эксперт ни в одном из этих вопросов, надеюсь, кто-то другой ответит на этот вопрос лучше, чем я.

Если вы хотите протестировать частный метод, тогда там в нем есть что-то сложное и вы, наверное, правы, захотите это проверить, это дизайнерский запах. Выставление метода в интерфейсе просто меняет один запах на другой, худший.

Пора рефакторингу :)

Обычно я выделяю внутреннюю сложность на вспомогательный класс. Однако проверьте метод на предмет «Зависть к особенностям» или «Неприемлемая близость». Возможно, для этого метода есть лучшее место для жизни. Теперь с помощью методов расширения в .net даже базовые типы могут быть хорошим кандидатом.

Удачи