Здравствуйте!

Поделитесь опытом тестирования приватных методов.

Лично я делаю так:

#if DEBUG
    public DriveInfo[] GetDrivesInfoAccessor()
    {
        return GetDrivesInfo();
    }
#endif
///...
private DriveInfo[] GetDrivesInfo()
{
 ///...
}

дальше пишу юнит тест:

#if DEBUG
        [Test]
        public void GetDrivesInfo()
        {
              ///...
        }
#endif

Меня больше всего удивило отсутствие обсуждений на форуме этого вопроса. Неужели никто не тестирует приватные методы?

Здравствуйте, _NT_, Вы писали:

_NT>Здравствуйте!

_NT>Поделитесь опытом тестирования приватных методов.

_NT>Лично я делаю так:

[skipped]

_NT>Меня больше всего удивило отсутствие обсуждений на форуме этого вопроса. Неужели никто не тестирует приватные методы?
Эээ... Я просто их тестирую в том классе, в котором они описаны. Т.е. написал — проверил — все норма? Да? Продолжаем. Нет? Ищем багу с отладчиком в зубах.

Здравствуйте, _NT_, Вы писали:

_NT>Здравствуйте!

_NT>Поделитесь опытом тестирования приватных методов.

_NT>Меня больше всего удивило отсутствие обсуждений на форуме этого вопроса. Неужели никто не тестирует приватные методы?

Как тестировать, это зависит от платформы/языка. В Java, например, можно извне доступиться к приватным методам при помощи несложных манипуляций с security и reflection.

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

Здравствуйте, _NT_, Вы писали:

_NT>Меня больше всего удивило отсутствие обсуждений на форуме этого вопроса. Неужели никто не тестирует приватные методы?

Лично я не тестирую.
Я тестирую только методы, которые можно нормально протестировать — которые обеспечивают функциональность. Остальное — уже проблема локализации ошибки.

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, _NT_, Вы писали:

_NT>>Меня больше всего удивило отсутствие обсуждений на форуме этого вопроса. Неужели никто не тестирует приватные методы?

Это ж озвереть можно, тестировать их все. Да и что там вообще тестировать?

Правильно dshe написал — если нужно тестировать приватный метод, может он уже и не приватый?

Здравствуйте, dshe, Вы писали:


D>Другой вопрос, а нужно ли их (приватные методы) тестировать? Если у тебя есть приватный метод, который обладает целостной функциональностью и его можно использовать (и, соответственно, тестировать) изолированно от других методов, то, может быть, он и не должен быть приватным?

Не согласен. Я считаю, что ЛЮБОЙ метод можно и нужно тестировать. И область его видимости никак не может влиять на принятие решения о необходимости тестирования.

Например — реализация абстрактных методов базового класса в его потомке. Разве они всегда public????

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

Но вопрос "как лучше проводить тестирования приватных методов?" остается открытым...

В тех редких случаях, когда мне надо тестировать приватные методы,
я просто в объявлении класса завожу нового друга (friend),
который соотвественно будет иметь доступ ко всем потрохам тестируемого класса.

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

Здравствуйте, _NT_, Вы писали:

D>>Другой вопрос, а нужно ли их (приватные методы) тестировать? Если у тебя есть приватный метод, который обладает целостной функциональностью и его можно использовать (и, соответственно, тестировать) изолированно от других методов, то, может быть, он и не должен быть приватным?

_NT>Не согласен. Я считаю, что ЛЮБОЙ метод можно и нужно тестировать. И область его видимости никак не может влиять на принятие решения о необходимости тестирования.
_NT>Например — реализация абстрактных методов базового класса в его потомке. Разве они всегда public????
_NT>Так что вы меня не убедили в бесполезности таких тестирований

Я бы тоже не стал тестировать приватные методы. Одна из причин — это будет мешать рефакторингу. От класса что требуется? Чтоб он соблюдал контракт а что там у него внутри как то не особо интересно. Соответственно и тестировать надо внешнее поведение (не методы не свойства а именно поведение то бишь реакцию на use case). ИМХО если есть насущная неодходимость в сабже надо подумать о рефакторинге.

_NT>Но вопрос "как лучше проводить тестирования приватных методов?" остается открытым.

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

Здравствуйте, _NT_, Вы писали:

_NT>Поделитесь опытом тестирования приватных методов.
IMHO, приватные методы тестируются косвенным образом посредством вызовов открытый методов, которые их используют.

Да и еще. Если все же очень хочется тестировать такие вещи... Есть пара технологий TestComplete Open Application и DebugAgent которые могут предоставить (с некоторыми ограничениями естественно) доступ к закрытм методам и свойствам. См. например http://automatedqa.com/products/testcomplete/tc_debuginfo.asp

http://www.codeproject.com/csharp/TestNonPublicMembers.asp

Статья посвящена именно етой теме (в том числе некоторие разяснения на тему "нужно ли тестироват прайвет")

Здравствуйте, Sergi, Вы писали:

S>http://www.codeproject.com/csharp/TestNonPublicMembers.asp

S>Статья посвящена именно етой теме (в том числе некоторие разяснения на тему "нужно ли тестироват прайвет")

В статье предложено делать использовать методи RunStaticMethod и RunInstanceMethod для визова приватних мотодов класса, но все же ето дает некоторую непрозрачность.

Мне видиться немного более прозрачний подход: если би била такая утилита, которая для сборки создает обертку (аналогично как студия создает обертки для сом компонент) в которой все обекти как в первой, но открити (все класи прокси).
Может ктото встречал такую утилиту?

Здравствуйте, _NT_, Вы писали:

_NT>Здравствуйте, dshe, Вы писали:


D>>Другой вопрос, а нужно ли их (приватные методы) тестировать? Если у тебя есть приватный метод, который обладает целостной функциональностью и его можно использовать (и, соответственно, тестировать) изолированно от других методов, то, может быть, он и не должен быть приватным?

_NT>Не согласен. Я считаю, что ЛЮБОЙ метод можно и нужно тестировать. И область его видимости никак не может влиять на принятие решения о необходимости тестирования.

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

_NT>Но вопрос "как лучше проводить тестирования приватных методов?" остается открытым...

По опыту — смысла не имеет. Т.к. не обладает целостной логикой, если обладает то почему эта логика скрытая? Тут скорее неверный дизайн.

Для проверки приватного состояния (внутренней согласованности) пишется метод типа AssertValid.

Здравствуйте, _NT_, Вы писали:

_NT>Поделитесь опытом тестирования приватных методов.

Можно делать юнит-тесты прямо в этом же классе. Но лично мне это кажется слишком громоздким.
Больше нравится такой подход — то что нужно тестировать объявляется как internal и тестируется отдельными классами тестов, входящими в ту же сборку. А эти классы, и только они, уже обрамляются #if DEBUG.
Третий вариант — вызовы приватных методов через reflection. Точно знаю что работать будет, но использовать пока не приходилось.

_NT>Меня больше всего удивило отсутствие обсуждений на форуме этого вопроса. Неужели никто не тестирует приватные методы?

Задавал как-то вопрос — никто не ответил. Всё-таки интерес к тестированию у программистов — маленький...

S>Может ктото встречал такую утилиту?

VS2005