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

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

MR>>Думаю, что имеет смысл делать модульные тесты отдельной сборкой и, соответственно, подключать тестируемые модули по-настоящему. Пару раз при написании юнит-тестов замечал, что какой-то тест требует нелогичной ссылки на модуль. Делался вывод, что какой-то код явно не на месте и происходил рефакторинг. ИМХО полезно.
0>А чем отличается процесс появления "нелогичной ссылки" при написании кода и при написании теста, что его выгоднее ловить именно при написании теста?

Наверное ничем не отличается. Другое дело, что при написании теста, клиентского кода может ещё и не быть

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

0>>Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни?

Мне иногда мешает, что в результат выдачи "Find All References" метода попадают еще и вызовы из юнит тестов. При наличии отдельной сборки с тестами это еще решаемо, при использовании одной — будет уже сложнее.

VS>Плюс помещения тестов в отдельную сборку — невозможность тестирования internal классов. На то они и internal.

Но иногда очень хочется

[assembly: InternalsVisibleTo("MyAssembly.UnitTests")]

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

VS>>>Плюс помещения тестов в отдельную сборку — невозможность тестирования internal классов. На то они и internal.
A>>Но иногда очень хочется

A>>

A>>[assembly: InternalsVisibleTo("MyAssembly.UnitTests")]
A>>

VS>Ну и кого ты обманул? Раз класс хочется тестировать изолированно, значит он — не деталь имплементации. Делай его public.

А почему если класс хочется тестировать изолированно, то он не деталь реализации?

Коллеги,
есть соблазн помещать код модульных тестов как можно ближе тестируемому коду. Конкретно — в те же сборки.
Ожидаемый бенефит: сокращение числа проектов, упрощение правил организации исходного кода, удобнее искать тесты на конкретный код.
Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни?
Сразу оговорюсь, речь идет не о коробочном продукте, так что поставки лишнего "веса" клиентам я не боюсь.
Может кто уже так делал, какие ваши впечатления?

В последнее время я все чаще пробую отходить от "golden path" от MS, и дышать, и кодить становится реально легче. Их послушать, так вообще надо солюшен из 20 проектов делать. Правда, пихать тесты в отдельную сборку -- это еще отцы TDD придумали. Но думаю, стоит попробовать.

Другое дело, что я предпочитаю структурировать тесты по фичам, а не по тестируемым классам, но это уже дело вкуса.

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

0>Коллеги,
0>есть соблазн помещать код модульных тестов как можно ближе тестируемому коду. Конкретно — в те же сборки.
0>Ожидаемый бенефит: сокращение числа проектов, упрощение правил организации исходного кода, удобнее искать тесты на конкретный код.
0>Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни?
0>Сразу оговорюсь, речь идет не о коробочном продукте, так что поставки лишнего "веса" клиентам я не боюсь.
0>Может кто уже так делал, какие ваши впечатления?

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

ulu>Другое дело, что я предпочитаю структурировать тесты по фичам, а не по тестируемым классам, но это уже дело вкуса.
Ты имеешь в виду модульные тесты и интеграционные/приёмочные и т.п. тесты?
Первые я предпочитаю структурировать по коду, вторые по фитчам.

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

0>Коллеги,
0>есть соблазн помещать код модульных тестов как можно ближе тестируемому коду. Конкретно — в те же сборки.

Думаю, что имеет смысл делать модульные тесты отдельной сборкой и, соответственно, подключать тестируемые модули по-настоящему. Пару раз при написании юнит-тестов замечал, что какой-то тест требует нелогичной ссылки на модуль. Делался вывод, что какой-то код явно не на месте и происходил рефакторинг. ИМХО полезно.

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

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

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

ulu>>Другое дело, что я предпочитаю структурировать тесты по фичам, а не по тестируемым классам, но это уже дело вкуса.
0>Ты имеешь в виду модульные тесты и интеграционные/приёмочные и т.п. тесты?
0>Первые я предпочитаю структурировать по коду, вторые по фитчам.

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

MR>Думаю, что имеет смысл делать модульные тесты отдельной сборкой и, соответственно, подключать тестируемые модули по-настоящему. Пару раз при написании юнит-тестов замечал, что какой-то тест требует нелогичной ссылки на модуль. Делался вывод, что какой-то код явно не на месте и происходил рефакторинг. ИМХО полезно.
А чем отличается процесс появления "нелогичной ссылки" при написании кода и при написании теста, что его выгоднее ловить именно при написании теста?

0>Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни?

Плюс помещения тестов в отдельную сборку — невозможность тестирования internal классов. На то они и internal.

VS>>Плюс помещения тестов в отдельную сборку — невозможность тестирования internal классов. На то они и internal.
A>Но иногда очень хочется

A>

A>[assembly: InternalsVisibleTo("MyAssembly.UnitTests")]
A>

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