Как улучшить время туда и обратно, делая TDD

Question

Я хочу улучшить время туда и обратно при выполнении TDD. Я предполагаю, что общее время компиляции для решения будет больше, но это не важно.

Справочная информация: Когда я смотрю окно вывода во время компиляции, когда я жду, пока запустится мой unittest, я вижу, что некоторое время затрачивается только на проверку того, что зависимые проекты не нужно строить.

Заявление: Разделение тестового проекта (сегодня около 20 тыс. Строк и зависимость от девяти других проектов) в меньшие тестовые проекты, где каждый тестовый проект тестирует меньшую часть кода, даст мне меньше зависимостей и, следовательно, увеличит время компиляции для тестового проекта, с которым я сейчас работаю.

Просмотры

Answer 1

Как правило, я бы предложил создать один тестовый проект для каждой сборки, поэтому он будет иметь одну зависимость от тестируемой сборки. Если тестируемая сборка называется MyCompany.MyProduct.Common, тестовый проект будет MyCompany.MyProduct.Common.Test.

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

Answer 2

Назовите меня сумасшедшим (я к этому привык!).

Я поместил свои тесты в ту же сборку, что и тестируемый код.

Код в пространстве имен N.M получает тесты в пространстве имен N.M.Tests.

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

Без сложности дополнительных зависимостей сборки из-за модульных тестов вы избежите исходной проблемы.

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

Answer 3

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

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