[.NET]: Юнит-тесты в тех же сборках, что и тестируемый код.
От: 0x7be СССР  
Дата: 26.12.11 08:51
Оценка:
Коллеги,
есть соблазн помещать код модульных тестов как можно ближе тестируемому коду. Конкретно — в те же сборки.
Ожидаемый бенефит: сокращение числа проектов, упрощение правил организации исходного кода, удобнее искать тесты на конкретный код.
Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни?
Сразу оговорюсь, речь идет не о коробочном продукте, так что поставки лишнего "веса" клиентам я не боюсь.
Может кто уже так делал, какие ваши впечатления?
Re: [.NET]: Юнит-тесты в тех же сборках, что и тестируемый к
От: ulu http://sm-art.biz
Дата: 26.12.11 10:28
Оценка:
В последнее время я все чаще пробую отходить от "golden path" от MS, и дышать, и кодить становится реально легче. Их послушать, так вообще надо солюшен из 20 проектов делать. Правда, пихать тесты в отдельную сборку -- это еще отцы TDD придумали. Но думаю, стоит попробовать.

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

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

0>Коллеги,

0>есть соблазн помещать код модульных тестов как можно ближе тестируемому коду. Конкретно — в те же сборки.
0>Ожидаемый бенефит: сокращение числа проектов, упрощение правил организации исходного кода, удобнее искать тесты на конкретный код.
0>Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни?
0>Сразу оговорюсь, речь идет не о коробочном продукте, так что поставки лишнего "веса" клиентам я не боюсь.
0>Может кто уже так делал, какие ваши впечатления?
Re[2]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
От: 0x7be СССР  
Дата: 26.12.11 11:00
Оценка:
Здравствуйте, ulu, Вы писали:

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

Ты имеешь в виду модульные тесты и интеграционные/приёмочные и т.п. тесты?
Первые я предпочитаю структурировать по коду, вторые по фитчам.
Re: [.NET]: Юнит-тесты в тех же сборках, что и тестируемый к
От: MaxRos  
Дата: 26.12.11 12:42
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Коллеги,

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

Думаю, что имеет смысл делать модульные тесты отдельной сборкой и, соответственно, подключать тестируемые модули по-настоящему. Пару раз при написании юнит-тестов замечал, что какой-то тест требует нелогичной ссылки на модуль. Делался вывод, что какой-то код явно не на месте и происходил рефакторинг. ИМХО полезно.
Re[3]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
От: ulu http://sm-art.biz
Дата: 26.12.11 12:55
Оценка:
Интеграционные, плавно переходящие в модульные (на самом деле, четкой границы между ними нет -- ведь модульные часто тестируют работу модуля, состоящего из нескольких классов).

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

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


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

0>Ты имеешь в виду модульные тесты и интеграционные/приёмочные и т.п. тесты?
0>Первые я предпочитаю структурировать по коду, вторые по фитчам.
Re[2]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
От: 0x7be СССР  
Дата: 26.12.11 13:07
Оценка:
Здравствуйте, MaxRos, Вы писали:

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

А чем отличается процесс появления "нелогичной ссылки" при написании кода и при написании теста, что его выгоднее ловить именно при написании теста?
Re[3]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
От: MaxRos  
Дата: 26.12.11 13:45
Оценка: 4 (1)
Здравствуйте, 0x7be, Вы писали:

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


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

0>А чем отличается процесс появления "нелогичной ссылки" при написании кода и при написании теста, что его выгоднее ловить именно при написании теста?

Наверное ничем не отличается. Другое дело, что при написании теста, клиентского кода может ещё и не быть
Re: [.NET]: Юнит-тесты в тех же сборках, что и тестируемый к
От: -VaS- Россия vaskir.blogspot.com
Дата: 06.01.12 19:10
Оценка:
0>Однако "golden path" от MS — это делать по тестовой сборке на каждую продуктовую. Какие тут могут быть подводные камни?

Плюс помещения тестов в отдельную сборку — невозможность тестирования internal классов. На то они и internal.
Re[2]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
От: andrey82  
Дата: 06.01.12 19:25
Оценка: 1 (1)
Здравствуйте, -VaS-, Вы писали:

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


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

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


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

[assembly: InternalsVisibleTo("MyAssembly.UnitTests")]
Re[3]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
От: -VaS- Россия vaskir.blogspot.com
Дата: 10.01.12 10:22
Оценка:
VS>>Плюс помещения тестов в отдельную сборку — невозможность тестирования internal классов. На то они и internal.
A>Но иногда очень хочется

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


Ну и кого ты обманул? Раз класс хочется тестировать изолированно, значит он — не деталь имплементации. Делай его public.
Re[4]: [.NET]: Юнит-тесты в тех же сборках, что и тестируемы
От: mrTwister Россия  
Дата: 14.01.12 14:42
Оценка: +1
Здравствуйте, -VaS-, Вы писали:

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

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

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


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


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