Тестирование закрытых классов, подписка на события

Что нужно делать чтобы подписаться на событие закрытого класса внутри тестового проекта?
Внутри аксессора нет события как такового, только доступ к методам add_SomeEvent и remove_SomeEvent, при этом при вызове метода студия жалуется на то что тип SomeClass_Accessor.SomeEventArgs не приводится к System.EventArgs. И это так.
Вопрос:
Как внутри теста подписываться на события теневого класса

0

KeBJIaP, похоже add_SomeEvent ожидает делегат другого типа. Посмотри его сигнатуру и передай экземпляр делегата нужного типа.

1

OwenGlendower, Нет, там похоже класс- обертка для EventArgs не наследуется от этого самого EventArgs, таким образом не отдать метод обработки (object, SomeEventArgs_Accessor) в делегат (object, EventArgs).

0

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

1

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

0

KeBJIaP, ну все алгоритмы, которые нужно тестировать, очевидно должны быть публичными. А приватным достаточно сделать простой класс, который эти алгоритмы выполняет.

Простой пример: я писал windows service, который периодически опрашивал БД и по результатам отправлял письма и смс. Мне нужно было протестировать всё это дело, но естественно я не могу этого сделать, не сделав методы публичными. В результаты, чтобы не плодить костыли, я просто вынес в отдельную длл весь функционал, а сервис занимался только вызовом библиотечных методов, ну а длл с публичными методами прекрасно поддается тестированию.

В итоге методы будут видеть только те, кто специально сослался на библиотеку, а этим людям, наверное, эти методы всё-таки нужны. А методы сервиса естественно были приватными. В результате и волки сыты, и овцы целы, и пастуху вечная память.

1

Psilon, С этим я конечно согласен, однако наличие в ВС автоматизированного тестирования наводит на мысль покрытия тестами ключевой функциональности. Для твоего примера, мне бы хотелось повесить тесты для функционала классификации данных из базы. Безусловно, для такого важного компонента стоит пожертвовать инкапсуляцией ради тестируемости. Но у меня например имеются 12 классов различных типов сообщений, я должен быть уверен что каждый тип упаковывается и распаковывается правильно вне зависимости от того что я меняю в коде. Нельзя же вешать 12 классов на публику, но и по условиям задачи библиотеку сделать не получится. Хотя если не выйдет нормальный тест написать, то придется так и делать. И, конечно не public а internal и поставить для теста internal visible.
Вообще, для решения конкретно моей проблемы требуется в метадате добавить что теневая оболочка класса SomeEventArgs наследуется от EventArgs. Как это можно провернуть не подскажешь?
А черт, оболочка уже унаследована от BaseShadow. Косяк.

Добавлено через 2 минуты
Ладно, тогда другой вопрос: Можно ли тестовые методы встраивать в не-тестовый класс

Добавлено через 12 секунд
Ладно, тогда другой вопрос: Можно ли тестовые методы встраивать в не-тестовый класс

0

KeBJIaP, Тестируются только публичные методы. Точка. Всё остальное - детали реализации. Следовательно если метод нужно тестировать - он должен быть публичный. Если класс нужно тестировать - он должен быть публичным. Тестирование "Деталей реализации" (а именно это и означает ключевое слово private/protected) - это костыли, которых по идее быть не должно и котороые методологией не поддерживаются. Ну я надеюсь, понятно, что должно быть больше 1 dll, одна - реализует библиотечку (то, что вы хотите протестировать и должно быть публичным), вторая - всё остальное. Проект с тестами - третий, тестирует только первую (с открытыми методами). Это как должно быть в теории. А как сделаете - так сделаете. Можно хоть через рефлексию доставать приватные методы, вопрос только - смысл? Если не захламлять область видимости, то достаточно вынести всё в отдельную дллку, если вопрос в "защищенности", то точно также, как тесты доставать будут приватные методы, сможет достать кто угодно. Вывод - бессмысленно городить костыли там, где они не нужны.

Добавлено через 52 секунды

Сообщение от KeBJIaP Ладно, тогда другой вопрос: Можно ли тестовые методы встраивать в не-тестовый класс

по идее можно. Но вопрос из серии "можно ли изменять неизменяемые шарповые строки", ответ - можно, но себе дороже. Хотя если выбрали пусть костылей и велосипедов, то это правильное решение!

1

Psilon, Мне не хочется идти путем костылей и велосипедов, поэтому я и интересуюсь возможностями.
Из твоих слов следует, что придется выбирать между покрытием тестами и инкапсуляцией, правильно я понимаю?

0

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

Если тебе нужно протестировать какой-то функционал, следовательно из п.1. этот функционал не должен скрываться. Это называется АПИ библиотеки.

Если тебе не надо показывать это пользователю твоей либы, то ты просто сделай еще одну библиотеку (а-ля LibraryUtils) и ссылайся на неё из свой либы. В итоге получаешь

1. Library - твоя библиотека, которая предоставляет АПИ для юзера.
2. LibraryUtils - твоя библиотека, которая предоставляет твоё внутреннее АПИ для твоей же библиотеки. Сюда отправляется под модификатор public всё, что ты хочешь протестировать, и под модификатор private всё, что не нужно в основной библиотеке.
3. LibraryTests - понятно
4. LibraryUtilsTests - понятно
5. UserCode - он ссылается на Library, он не видит публичные классы и методы из LibraryUtils. В результате твоя инкапсуляция не нарушается.

Конечно, он может сослаться и на LibraryUtils и вызывать твои публичные методы, предназначенные для внутреннего использования, но он точно также при большом желании сможет вызывать их напрямую через рефлексию. Модификаторы доступа являются рекомендательными (мы НЕ ХОТИМ показывать это поле), а не запретительными (мы НЕ ДАДИМ вам посмотреть это поле). Поэтому пытаться с их помощью кому-то что-то запретить нельзя. Можно просто попросить юзеров следовать Fair Use: не ссылайтесь на служебную библиотеку, и всё.

1

Psilon, Спасибо, буду переделывать модули.

0

KeBJIaP, да нз, обращайся

0