Тестирование закрытых методов через разделяемые классы

@toleg · Регистрация: 29.10.2013

Студворк — интернет-сервис помощи студентам

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

В настоящее время я стараюсь практически все свои непубличные методы реализовать как internal и тестировать их из дружественной сборки - способ №2 из статьи на хабре Как тестировать не-публичные методы в .NET.

Однако такой подход, понятно, засоряет интерфейс. Хотелось бы делать такие методы private, но способы их тестирования, например, описанные в той же статье, довольно замороченные - через рефлексию и пр. И часто не позволяют вызывать метод в естественном виде obj.SomeMethod(), что, как я понимаю, нарушает принципы юнит-тестирования и TDD.

Так вот, пришла сейчас в голову идея как тестировать private-методы: оформить класс, содержащий их, как partial. В одной части тестируемого partial-класса будут private-методы, которые нужно тестировать. В другой части - создаем вложенный класс, с юнит-тестами. Помечаем вторую часть partial-класса директивами препроцессора типа #if DEBUG или #if UNITTESTS. Соответственно, будем иметь возможность протестировать private-методы, при компиляции для юнит-тестов, и возможность удалять методы юнит-тестов при создании production-сборок.

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

В общем, вот такая идея.
Какие недостатки такого подхода приходят в голову:
1) Мы вторгаемся в реализацию класса со своими методами юнит-тестов.
2) Production-код фактически не тестируется юнит-тестами. Если юнит-тесты что-то изменили / испортили в изначальном коде, это выяснится только в продакшене.
3) Есть опасения насчет корректности работы xUnit с этой конструкцией из вложенных классов.

Для устранения недостатка №2 нужно будет дополнительно создавать юнит-тесты для internal, protected, public-методов. И уже их можно будет размещать в дружественной сборке. Собственно, я бы и так это сделал, так что объем работы, судя по всему, не изменится.

Как вы смотрите на такую идею?

@IamRain · 04.10.2014, 21:50

Сообщение от toleg

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

Информация к размышлению: А надо ли заниматься извращениями?

Добавлено через 2 минуты
Обратите внимание на последний абзац, если нет желания читать весь пост.

@toleg · 08.10.2014, 17:55 **[ТС]**

Спасибо за статью. Прочитал ее бегло, и комментарии. Надо будет поразбираться.

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

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

Впрочем, не хотелось бы тут уходить в оффтоп, обсуждая надобность тестирования закрытых методов. Если вы знакомы с книгой "Gerard Meszaros - xUnit Test Patterns. 2007" (есть и на русском), то наверное в курсе, что паттернов и приемов юнит-тестирования существует немалое количество, причем многие из них противоречат друг другу. Или если выразить более мягко, являются альтернативами друг друг.

Товарищ Meszaros приводит объективные аргументы за и против. Я же от себя в первом посте добавил, что тестирование приватных методов - одна из моих привычек при работе со сложным кодом. Часто такое тестирование - часть эксперимента, в рамках которого проверяется, как работает метод, как бросает исключения. После такого прототипирования и профилирования часто в итоге получаю как готовый метод, так и его тесты. Ну так тесты уже есть - не выбрасывать же их теперь?

Автор статьи, которую вы приводите пишет: "И новые классы я не буду делать публичными, а сделаю внутренними, поэтому клиенты нашего модуля не узнают об увеличении количества классов."

Я и сам такой подход сейчас практикую, и хуже того - часто приватные методы делаю internal. Но такая практика тоже временами напрягает, поскольку засоряет интерфейс. Интерфейс, который виден в IntelliSense при вызове методов класса из той же сборки - методы, которые по уму должны быть приватными.

Ну в общем, тут долго можно говорить. Есть у этого и свои плюсы, и свои минусы...

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

@IamRain · 08.10.2014, 18:20

Сообщение от toleg

Мало того, что метод станет публичным, но еще и будет на одну сущность больше.
Я искренне не понимаю."

toleg, у меня не так много опыта в разработке, особенно в командной, чтобы что-то убежденно об этом говорить, но здравый смысл подсказывает, если детали реализации (приватные методы) написаны с ошибками в логике, то это обязательно всплывет при передаче "правильных" входных параметров в публичном методе, в котором вызываются эти детали реализации (при условии что сам класс спроектирован правильно).
Что касается выделения отдельных сущностей, то это вполне естественно: если видно, что класс делает слишком много, то ясно понятно, что можно попробовать выделить отдельные сущности, пускай даже приватные методы станут публичными, либо класс internal. "Любая сложная система есть совокупность ... " (С).
Это ведь, по-моему, и есть основы проектирования - правильное выделение самостоятельных сущностей и организация их взаимодействия.

@I2um1 · 09.10.2014, 10:19

Мне интересно: что предпримет ТС, когда столкнется с действительно сложной логикой.
Причем я говорю о вполне обыденных вещах, которые часто встречаются как на клиентских, так и на серверных программах. К пример класс, который описывает поведение работы некоторой службы и зависим от внешних ресурсов (будь-то ReST, сокеты, общение с каким-либо хранилищем данных - не обязательно СУБД) и, что не мало важно, ведет себя по разному в зависимости от текущего времени и создаваемой нагрузки. У такого класса обычно всего два метода (Start и Stop), а единственное состояние - информация о том, запущена ли эта служба.
В лес далеко не ходи по грибы, на мой взгляд, самый простой пример: служба для Rss-читалки под Android, которая за определенные временные участки и при определенных условиях диктуемых устройством (например airplane mode), собирает с определенных web-ресурсов, указанных пользователем, новостные ленты и сохраняет собранные данные (в определенной форме) в локальную базу данных, где не факт, что хватит места на карте памяти (если она вообще есть).
Возможно тогда-то и узнает, что помимо Stubs, есть еще Mock, Moles, Shims. Плюс, начиная вроде с 2012 студии для каждой сборки можно генерировать фейковую сборку через контекстное меню "Add fakes assembly" (работает даже с системными сборками). Сразу ощутишь правильность своей архитектуры. =)

@toleg · 09.10.2014, 23:15 **[ТС]**

Сообщение от IamRain

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

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

К примеру Месарош так это описывает: "If we want to test the individual steps of a complex algorithm individually"

Сообщение от IamRain

Что касается выделения отдельных сущностей, то это вполне естественно: если видно, что класс делает слишком много, то ясно понятно, что можно попробовать выделить отдельные сущности, пускай даже приватные методы станут публичными, либо класс internal. "Любая сложная система есть совокупность ... " (С).
Это ведь, по-моему, и есть основы проектирования - правильное выделение самостоятельных сущностей и организация их взаимодействия.

Кроме того, я сейчас ваяю довольно крупное приложение и чтобы сохранить себе моск, стараюсь работать этакими тематическими блоками. По-максимуму отработать какой-то один блок: создать, оттестить, оформить для него весьма ограниченный интерфейс и потом забыть о его реализации, пользуясь вместо сотни его private / internal методов десятком-другим публичных методов. Иногда такой блок совпадает со сборкой, и это удобно, поскольку тогда все internal-методы становятся невидимыми для других сборок.

Но иногда не совпадает, и тогда все эти internal-сущности (типы, их члены и пр.) висят у меня в IntelliSense и портят весь интерфейс.

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

Такие же рекомендации дает и Рихтер, хотя, может, я и слишком буквально его понимаю:

When defining a class, I always explicitly make it sealed unless I truly intend for the class to be a base class that allows specialization by derived classes... I also default to making the class internal unless I want the class to be publicly exposed outside of my assembly...
Inside the class, I always define my methods, properties, and events as private and nonvirtual. Fortunately, C# defaults to this as well. Certainly, I’ll make a method, property, or event public to expose some functionality from the type. I try to avoid making any of these members protected or internal, because this would be exposing my type to some potential vulnerability

Добавлено через 10 минут

Сообщение от I2um1

что предпримет ТС

Топик-стартер, вы имеете в виду?

Возможно тогда-то и узнает, что помимо Stubs, есть еще Mock, Moles, Shims

Да, возможно, узнаю. Хотя со стабами и моками приходится довольно плотно работать.

Сразу ощутишь правильность своей архитектуры. =)

Ну понятно. И топик-стартер недалекий, и архитектура у него никуда не годится...

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

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

Добавлено через 9 минут
Ну а по сути-то вопроса у вас найдутся замечания?

Например, сегодня нашел нечто похожее у Альбахари:

The following directive instructs the compiler to include the code that follows if the TESTMODE symbol is defined and the DEBUG symbol is not defined:
#if TESTMODE && !DEBUG

An attribute decorated with the Conditional attribute will be compiled only if a given preprocessor symbol is present. For example:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// file1.cs
#define DEBUG
 
using System;
using System.Diagnostics;
 
[Conditional("DEBUG")]
public class TestAttribute : Attribute {}
 
 
// file2.cs
#define DEBUG
 
[Test]
class Foo
{
  [Test]
  string s;
}

Совпадает идея модификации кода для целей тестирования и отладки путем использования препроцессорных директив.

@I2um1 · 10.10.2014, 21:56

Сообщение от toleg

И топик-стартер недалекий, и архитектура у него никуда не годится...

Думать совсем не желаешь, а я ведь дал подсказку: проблема в архитектуре. Есть такой принцип как разделение ответственности, тем более парадигма ООП способствует этому. Тестируемый код нельзя изменять ради тестов - нарушение принципов SOLID.

Сообщение от toleg

Я вот изначально не хотел скатываться в оффтоп...

Это не оффтоп, а способ решения.

Сообщение от toleg

И главное - я не очень понимаю, откуда такая категоричность? Да, тестирование приватных методов имеет кучу недостатков.

А это твое умозаключение, я этого не утверждал.

Сообщение от toleg

Такие же рекомендации дает и Рихтер

В тех строчках речь о другом. Мешаешь все в одну кучу.

@Cyberatino2 · 11.10.2014, 01:27

Привет.
Может, такое извращение.

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class A
{
   public M()
   {
       C();
   }
   protected internal C()
   {
   }
}
 
[TestClass]
public class ATest : A
{
   [TestMethod]
   public void TouchMeTouchMeNow_AndTestC()
   {
       Assert.AreEqual("", C());
   }
}

Не по теме:

Свою позицию высказываю сразу - я против тестирования приватов.
Объект выставляет наружу морду, с которой взаимодействуют все, кому не лень, потому что им от объекта ничего, кроме морды не нужно. Для юзера инстанса он не более, чем конечный автомат. Поэтому в корректности чего ты собрался убеждаться? Что твой приват работает ожидаемо? Но потребителю кода на это насрать. Его волнует лишь то, чтобы a + b было c. При этом потребителем кода являешься в каком-то смысле ты сам, потому что сам же потом работаешь со своей писаниной.
Похоже, ты просто фанат спеков и тебе нравится углубляться в тонкости платформы. Но к практическому смыслу эффективного проектирования это отношения не имеет.

Новые блоги и статьи Все статьи Все блоги /
Философия технологии iceja 01.02.2026 На мой взгляд у человека в технических проектах остается роль генерального директора. Все остальное нейронки делают уже лучше человека. Они не могут нести предпринимательские риски, не могут. . .	SDL3 для Web (WebAssembly): Вывод текста со шрифтом TTF с помощью SDL3_ttf 8Observer8 01.02.2026 Содержание блога В этой пошаговой инструкции создадим с нуля веб-приложение, которое выводит текст в окне браузера. Запустим на Android на локальном сервере. Загрузим Release на бесплатный. . .	SDL3 для Web (WebAssembly): Сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	SDL3 для Web (WebAssembly): Установка Emscripten SDK (emsdk) и CMake для сборки C и C++ приложений в Wasm 8Observer8 30.01.2026 Содержание блога Для того чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. . . .
SDL3 для Android: Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .	SDL3 для Android: Загрузка PNG с альфа-каналом с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 28.01.2026 Содержание блога SDL3 имеет собственные средства для загрузки и отображения PNG-файлов с альфа-каналом и базовой работы с ними. В этой инструкции используется функция SDL_LoadPNG(), которая. . .	SDL3 для Android: Загрузка PNG с альфа-каналом с помощью SDL3_image 8Observer8 27.01.2026 Содержание блога SDL3_image - это библиотека для загрузки и работы с изображениями. Эта пошаговая инструкция покажет, как загрузить и вывести на экран смартфона картинку с альфа-каналом, то есть с. . .

@toleg 1 / 1 / 0 Регистрация: 29.10.2013 Сообщений: 9

	Тестирование закрытых методов через разделяемые классы 04.10.2014, 18:25. Показов 5543. Ответов 7 Метки нет (Все метки) Я - большой любитель тестирования непубличных методов. Связано это с тем, что обычно публичных методов у меня немного и работают они через вызовы различных непубличных. При чем последние иной раз имеют довольно сложную реализацию. В настоящее время я стараюсь практически все свои непубличные методы реализовать как internal и тестировать их из дружественной сборки - способ №2 из статьи на хабре Как тестировать не-публичные методы в .NET. Однако такой подход, понятно, засоряет интерфейс. Хотелось бы делать такие методы private, но способы их тестирования, например, описанные в той же статье, довольно замороченные - через рефлексию и пр. И часто не позволяют вызывать метод в естественном виде obj.SomeMethod(), что, как я понимаю, нарушает принципы юнит-тестирования и TDD. Так вот, пришла сейчас в голову идея как тестировать private-методы: оформить класс, содержащий их, как partial. В одной части тестируемого partial-класса будут private-методы, которые нужно тестировать. В другой части - создаем вложенный класс, с юнит-тестами. Помечаем вторую часть partial-класса директивами препроцессора типа #if DEBUG или #if UNITTESTS. Соответственно, будем иметь возможность протестировать private-методы, при компиляции для юнит-тестов, и возможность удалять методы юнит-тестов при создании production-сборок. В качестве фреймворка я использую xUnit.net, который, в отличие от NUnit, для каждого юнит-теста создает новый экземпляр объекта, содержащего метод этого юнит-теста. Поэтому и приходится помещать юнит-тесты не в тестируемый класс, а в специальный вложенный. В общем, вот такая идея. Какие недостатки такого подхода приходят в голову: 1) Мы вторгаемся в реализацию класса со своими методами юнит-тестов. 2) Production-код фактически не тестируется юнит-тестами. Если юнит-тесты что-то изменили / испортили в изначальном коде, это выяснится только в продакшене. 3) Есть опасения насчет корректности работы xUnit с этой конструкцией из вложенных классов. Для устранения недостатка №2 нужно будет дополнительно создавать юнит-тесты для internal, protected, public-методов. И уже их можно будет размещать в дружественной сборке. Собственно, я бы и так это сделал, так что объем работы, судя по всему, не изменится. Как вы смотрите на такую идею? 0

@toleg 1 / 1 / 0 Регистрация: 29.10.2013 Сообщений: 9
	08.10.2014, 17:55 [ТС]
	Спасибо за статью. Прочитал ее бегло, и комментарии. Надо будет поразбираться. Последний абзац вы имели в виду этот: "Любые условия и ветвления в закрытых методах представляют собой граничные условия класса, которые вы наверняка сможете протестировать через открытый интерфейс. Если же это окажется слишком сложным, то это говорит о том, что класс делает слишком многое и требуется разбитие его на более мелкие составляющие, которые вы спокойно сможете протестировать автономно. "? Там же один товарищ прокомментировал так: "Получается, что если хочется написать тесты на закрытый метод, то делать его публичным некошерно, зато вынести в отдельный класс - правильно? Мало того, что метод станет публичным, но еще и будет на одну сущность больше. Я искренне не понимаю." Впрочем, не хотелось бы тут уходить в оффтоп, обсуждая надобность тестирования закрытых методов. Если вы знакомы с книгой "Gerard Meszaros - xUnit Test Patterns. 2007" (есть и на русском), то наверное в курсе, что паттернов и приемов юнит-тестирования существует немалое количество, причем многие из них противоречат друг другу. Или если выразить более мягко, являются альтернативами друг друг. Товарищ Meszaros приводит объективные аргументы за и против. Я же от себя в первом посте добавил, что тестирование приватных методов - одна из моих привычек при работе со сложным кодом. Часто такое тестирование - часть эксперимента, в рамках которого проверяется, как работает метод, как бросает исключения. После такого прототипирования и профилирования часто в итоге получаю как готовый метод, так и его тесты. Ну так тесты уже есть - не выбрасывать же их теперь? Автор статьи, которую вы приводите пишет: "И новые классы я не буду делать публичными, а сделаю внутренними, поэтому клиенты нашего модуля не узнают об увеличении количества классов." Я и сам такой подход сейчас практикую, и хуже того - часто приватные методы делаю internal. Но такая практика тоже временами напрягает, поскольку засоряет интерфейс. Интерфейс, который виден в IntelliSense при вызове методов класса из той же сборки - методы, которые по уму должны быть приватными. Ну в общем, тут долго можно говорить. Есть у этого и свои плюсы, и свои минусы... Что же касается моей идеи, описанной в первом посте, то чем больше я о ней думаю, тем больше такая конструкция мне кажется извратной. Впрочем, если будут положительные моменты по прошествии времени, постараюсь их тоже упомянуть. 0

@I2um1 Злой няш 2136 / 1505 / 565 Регистрация: 05.04.2010 Сообщений: 2,881
	09.10.2014, 10:19
	Мне интересно: что предпримет ТС, когда столкнется с действительно сложной логикой. Причем я говорю о вполне обыденных вещах, которые часто встречаются как на клиентских, так и на серверных программах. К пример класс, который описывает поведение работы некоторой службы и зависим от внешних ресурсов (будь-то ReST, сокеты, общение с каким-либо хранилищем данных - не обязательно СУБД) и, что не мало важно, ведет себя по разному в зависимости от текущего времени и создаваемой нагрузки. У такого класса обычно всего два метода (Start и Stop), а единственное состояние - информация о том, запущена ли эта служба. В лес далеко не ходи по грибы, на мой взгляд, самый простой пример: служба для Rss-читалки под Android, которая за определенные временные участки и при определенных условиях диктуемых устройством (например airplane mode), собирает с определенных web-ресурсов, указанных пользователем, новостные ленты и сохраняет собранные данные (в определенной форме) в локальную базу данных, где не факт, что хватит места на карте памяти (если она вообще есть). Возможно тогда-то и узнает, что помимо Stubs, есть еще Mock, Moles, Shims. Плюс, начиная вроде с 2012 студии для каждой сборки можно генерировать фейковую сборку через контекстное меню "Add fakes assembly" (работает даже с системными сборками). Сразу ощутишь правильность своей архитектуры. =) 0