#.net #unit-testing #tdd
#.net #модульное тестирование #tdd
Вопрос:
В проекте, над которым я работаю, мы разрабатываем на основе тестирования (TDD). Мы создаем различные уровни абстракции и тестируем каждый из них отдельно, используя mocks для зависимостей нижнего уровня, где это уместно.
В результате мы обычно получаем небольшую горстку кратких модульных тестов (TestMethod) для каждого метода в целевом классе.
Я часто ловлю себя на том, что смотрю на реализацию метода и хочу увидеть список тестовых методов модульного тестирования, которые его тестируют. Обычно я просто выполняю ‘find all usages’ по имени метода, чтобы получить список соответствующих модульных тестов (среди всех других использований в решении).
Мой вопрос: есть ли какие-либо метаданные, которые можно использовать в TestMethod (например, атрибут или <see cref="..."/> , который используется для документации), которые указывают, какой метод он на самом деле тестирует? Делаем еще один шаг вперед: могу ли я затем быстро перейти к этим тестам, учитывая, что я нахожусь в реализации?
Для меня выгода была бы исключительно в плане производительности / навигации. (Редактировать): учитывая мой первый комментарий ниже, можно утверждать, что такие метаданные могли бы способствовать хорошему дизайну тестов, а также реализаций.
Мы используем Visual Studio 2012 с Resharper 7.
Комментарии:
1. Я полагаю, что такие метаданные дали бы ложное ощущение согласованности между тестами и реализацией. Как насчет тестов, которые косвенно используют эти методы, вызывая другие методы, которые, в свою очередь, вызывают тот, на который вы смотрите? Или методы, которые вообще не тестируются напрямую, но покрываются другими косвенными тестами?
2. Спасибо, Дэвид. О сплоченности: мой аргумент заключается в том, что такие метаданные будут интерпретироваться как «это тест для этого метода». Такая согласованность между методом модульного тестирования и методом реализации кажется мне естественной. По поводу других ваших комментариев: Я бы сказал, что такие метаданные будут 1) поощрять хорошо разработанные тесты, в которых каждый метод тестирования выполняет свою задачу кратко, БЕЗ необходимости вызывать какой-либо другой уровень тестирования, и 2) поощрять хорошо разработанные реализации… если у меня есть метод, который не тестируется напрямую, то, вероятно, у меня либо непроверенная функциональность, либо мои тесты верхнего уровня слишком сложны.