Коллеги,
есть соблазн помещать код модульных тестов как можно ближе тестируемому коду. Конкретно — в те же сборки.
Ожидаемый бенефит: сокращение числа проектов, упрощение правил организации исходного кода, удобнее искать тесты на конкретный код.
Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни?
Сразу оговорюсь, речь идет не о коробочном продукте, так что поставки лишнего "веса" клиентам я не боюсь.
Может кто уже так делал, какие ваши впечатления?
Re: [.NET]: Юнит-тесты в тех же сборках, что и тестируемый к
В последнее время я все чаще пробую отходить от "golden path" от MS, и дышать, и кодить становится реально легче. Их послушать, так вообще надо солюшен из 20 проектов делать. Правда, пихать тесты в отдельную сборку -- это еще отцы TDD придумали. Но думаю, стоит попробовать.
Другое дело, что я предпочитаю структурировать тесты по фичам, а не по тестируемым классам, но это уже дело вкуса.
Здравствуйте, 0x7be, Вы писали:
0>Коллеги, 0>есть соблазн помещать код модульных тестов как можно ближе тестируемому коду. Конкретно — в те же сборки. 0>Ожидаемый бенефит: сокращение числа проектов, упрощение правил организации исходного кода, удобнее искать тесты на конкретный код. 0>Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни? 0>Сразу оговорюсь, речь идет не о коробочном продукте, так что поставки лишнего "веса" клиентам я не боюсь. 0>Может кто уже так делал, какие ваши впечатления?
Re[2]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
Здравствуйте, ulu, Вы писали:
ulu>Другое дело, что я предпочитаю структурировать тесты по фичам, а не по тестируемым классам, но это уже дело вкуса.
Ты имеешь в виду модульные тесты и интеграционные/приёмочные и т.п. тесты?
Первые я предпочитаю структурировать по коду, вторые по фитчам.
Re: [.NET]: Юнит-тесты в тех же сборках, что и тестируемый к
Здравствуйте, 0x7be, Вы писали:
0>Коллеги, 0>есть соблазн помещать код модульных тестов как можно ближе тестируемому коду. Конкретно — в те же сборки.
Думаю, что имеет смысл делать модульные тесты отдельной сборкой и, соответственно, подключать тестируемые модули по-настоящему. Пару раз при написании юнит-тестов замечал, что какой-то тест требует нелогичной ссылки на модуль. Делался вывод, что какой-то код явно не на месте и происходил рефакторинг. ИМХО полезно.
Re[3]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
Интеграционные, плавно переходящие в модульные (на самом деле, четкой границы между ними нет -- ведь модульные часто тестируют работу модуля, состоящего из нескольких классов).
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, ulu, Вы писали:
ulu>>Другое дело, что я предпочитаю структурировать тесты по фичам, а не по тестируемым классам, но это уже дело вкуса. 0>Ты имеешь в виду модульные тесты и интеграционные/приёмочные и т.п. тесты? 0>Первые я предпочитаю структурировать по коду, вторые по фитчам.
Re[2]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
Здравствуйте, MaxRos, Вы писали:
MR>Думаю, что имеет смысл делать модульные тесты отдельной сборкой и, соответственно, подключать тестируемые модули по-настоящему. Пару раз при написании юнит-тестов замечал, что какой-то тест требует нелогичной ссылки на модуль. Делался вывод, что какой-то код явно не на месте и происходил рефакторинг. ИМХО полезно.
А чем отличается процесс появления "нелогичной ссылки" при написании кода и при написании теста, что его выгоднее ловить именно при написании теста?
Re[3]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, MaxRos, Вы писали:
MR>>Думаю, что имеет смысл делать модульные тесты отдельной сборкой и, соответственно, подключать тестируемые модули по-настоящему. Пару раз при написании юнит-тестов замечал, что какой-то тест требует нелогичной ссылки на модуль. Делался вывод, что какой-то код явно не на месте и происходил рефакторинг. ИМХО полезно. 0>А чем отличается процесс появления "нелогичной ссылки" при написании кода и при написании теста, что его выгоднее ловить именно при написании теста?
Наверное ничем не отличается. Другое дело, что при написании теста, клиентского кода может ещё и не быть
Re: [.NET]: Юнит-тесты в тех же сборках, что и тестируемый к
Здравствуйте, -VaS-, Вы писали:
0>>Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни?
Мне иногда мешает, что в результат выдачи "Find All References" метода попадают еще и вызовы из юнит тестов. При наличии отдельной сборки с тестами это еще решаемо, при использовании одной — будет уже сложнее.
VS>Плюс помещения тестов в отдельную сборку — невозможность тестирования internal классов. На то они и internal.
Здравствуйте, -VaS-, Вы писали:
VS>>>Плюс помещения тестов в отдельную сборку — невозможность тестирования internal классов. На то они и internal. A>>Но иногда очень хочется
A>>
