TDD с большим C # решением практически невозможно из-за медленной скорости компиляции

Question

Я работаю над большим решением с 60 сборками. Существует множество сборок, определяющих общие части решения, а затем несколько сборок точки входа в систему.

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

Что является лучшей практикой - сократить время сборки с нынешних 75 секунд до более приемлемо 5 секунд или около того? Это снова сделает возможным TDD.

При выполнении модульных тестов некоторым классам требуются макеты, определенные интерфейсами из других сборок, и на них следует ссылаться в тестовой сборке. Таким образом, наличие единой ссылки на другие сборки не всегда возможно, кроме как на самом низком уровне решения.

Answer 1

ИМХО проблема заключается здесь: «поскольку тестовая сборка ссылается на различные слои решения.»
У вас должна быть одна тестовая сборка на каждую сборку, которую вы хотите протестировать.
Когда вы все еще ссылаетесь на множество сборок в каждой изВ ваших тестовых сборках возникла другая проблема: вы создаете интеграционные тесты.Это не то, что вы хотите сделать в TDD.

В дополнение к обновлению вашего вопроса:
Обычно вы определяете интерфейсы в другой сборке, чем реализация.Таким образом, изменение реализации низкоуровневого класса не должно влиять на классы более высокого уровня, использующие эти интерфейсы ...

Answer 2

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

Есть еще несколько вещей, которые легче сделать:

• Объединение небольших проектов в более крупные проекты, поскольку при создании решения возникают большие накладные расходы на каждый проект.(Используйте nDepend , если необходимо управлять вызовами между слоями, правила могут быть определены в " Code Query Language " и затем проверены как часть вашей сборки)

• Заставьте все проекты встраиваться в какой-то выходной каталог, а затем установите для параметра «копировать локальный» значение «ложь» во всех ссылках проекта - это может привести к значительному увеличению скорости из-за уменьшения ввода-вывода.

  Включите проверку на вирусы, чтобы увидеть, имеет ли это большое значение;если это так, найдите более быструю проверку на вирусы или исключите «горячие» папки из проверки на наличие вирусов

• Используйте монитор производительности и внутренний инструмент sys, чтобы увидеть, каккомпиляции занимают так много времени.

• Рассмотрим оперативный диск для установки выходного каталога.

• Рассмотрим использование SSD, это большой выигрыш и они дешевеют.

• Временами больший объем памяти может иметь большой эффект - (уменьшив баран в машине, если вы сильно замедлились, удалив маленького барана, выможет увеличить скорость, добавив больше)

• Удалите ненужные ссылки на проекты (возможно, вам придется сначала удалить ненужные «использования»)

(Более быстрая сборка также ускорит рефакторинг!)

Answer 3

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

При работе с TDD и большими проектами проблема обычно заключается в медленном выполнении теста, а не во время компиляции.Пусть весь процесс сборки будет обрабатываться какой-то специальной машиной сборки и выполнять весь процесс сборки и весь модульный тестовый запуск только при регистрации.

Это вернет вашу разработку к обычному TDD.