TDD - создание нового класса в пустом проекте, чтобы сделать зависимости явными по мере их добавления

Question

Используя TDD, я рассматриваю возможность создания (одноразового) пустого проекта в качестве Test-harness / контейнера для каждого нового класса, который я создаю.Так что это существует в маленьком частном пузыре.

Когда у меня есть зависимость и мне нужно получить что-то еще из более широкого проекта, мне нужно проделать некоторую работу, чтобы добавить это в мой чистый файл проекта, и я вынужден подумать об этой зависимости.Если предположить, что мой класс несет единственную ответственность, тогда мне не нужно делать это очень много.

Еще одно преимущество - это почти мгновенный цикл компиляции / тестирования / редактирования.

Как только я доволенкласс, затем я могу добавить его в основной проект / решение.

Кто-нибудь делал что-то подобное раньше или это безумие?

Answer 1

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

Преимущества могут быть:

• обязательно не изменяйте основной проект или не фиксируйте случайно
• зависимостей нет, с уверенностью

Недостатками могут быть:

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

В целом, боюсь, это не поможет сэкономить время ...: - (

Answer 2

Я был на презентации по использованию Endeavor . Одним из понятий, от которых они сильно зависели, было разделение, как вы предлагаете:

• сервис в отдельном решении с собственным жгутом для испытаний

Endeavour является в двух словах мощной средой разработки / плагином для VS, который помогает архивировать эти вещи. Среди множества других вещей он также подключается к / создает ночную сборку из SourceSafe, чтобы определить, какие библиотеки собирают и помещает их в общую папку.

Когда вы создаете код, который зависит от другого сервиса, вы ссылаетесь не на проект VS, а на скомпилированную DLL в общей папке.

Благодаря этому устраняются некоторые недостатки, предложенные KLE:

• Проекты в зависимости от вашего кода ссылаются на DLL, а не на ваш проект (выигрыш времени сборки)
• Когда ваш проект не удастся построить, он не нарушит интеграцию; они зависят от DLL, которая все еще доступна из последней работающей сборки
• Все классы видимы - нет

Средний этаж:

• Вы ДЕЙСТВИТЕЛЬНО должны думать о зависимости, более чем о «простых» установках.
• Еще стоит время

Но, конечно, есть и обратная сторона:

• Нелегко обнаружить циклическую зависимость

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