Как иметь дело с длительными Модульными тестами?

Если вы используете ядро ​​Entity Framework, есть команда

Scaffold-DbContext "Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -Tables *insert your tables/views here* -OutputDir Models

Существует подробное руководство Начало работы с существующей базой данных

Надеюсь, это поможет

6
задан Bill the Lizard 8 May 2014 в 19:32
поделиться

6 ответов

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

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

Можно ли сказать, какие тесты Вы имеете, которые являются модульными тестами (тестирующий только 1 вещь) по сравнению с функциональными испытаниями (тестирующий 2 или больше вещи одновременно)? Которые быстры и которые являются медленными?

10
ответ дан 8 December 2019 в 02:53
поделиться

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

8
ответ дан 8 December 2019 в 02:53
поделиться

Я рекомендовал бы объединенный подход к Вашей проблеме:

  • Часто выполняйте подмножество тестов, которые являются близко к коду, который Вы вносите изменениями в (например, тесты от того же пакета, модуля или подобный). Менее часто запускайте тесты, которые дальше удалены из кода, Вы в настоящее время продолжаете работать.
  • Разделите свой комплект по крайней мере в двух: быстро выполнение и медленные запускающие тесты. Запускайте быстрые рабочие тесты чаще.
  • Полагайте, что наличие части из менее вероятно для проваливания тестов только быть выполненным автоматизированным продолжает сервер интеграции.
  • Изучите методы для улучшения производительности тестов. Самое главное путем замены доступа для замедления системных ресурсов более быстрыми фальшивками. Например, используйте в потоках памяти вместо файлов. Блокируйте/дразните http доступ. и т.д.
  • Изучите, как использовать методы повреждения зависимости с низким риском, как перечисленные в (очень наиболее рекомендуемый) книга, "Работающая Эффективно С Унаследованным кодом". Они позволяют Вам эффективно делать свой код более тестируемым, не применяя рефакторинги высокого риска (часто путем временного создания фактического дизайна хуже, как повреждающаяся инкапсуляция, пока Вы не можете осуществить рефакторинг к лучшему дизайну с системой поддержки тестов).

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

8
ответ дан 8 December 2019 в 02:53
поделиться

Во-первых, это не модульные тесты.

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

Во-вторых, не бойтесь дразнить часть Http приложения. Если Вы действительно хотите к модульному тесту приложение, это - НЕОБХОДИМОСТЬ. Если Ваш не готовый сделать это, Вы пропадаете зря намного больше времени, пытаясь протестировать Вашу фактическую логику, ожидая Запросов HTTP для возвращения и пытаясь настроить данные.

Я сохранил бы Ваши тесты степени интеграции, но стремился бы создать реальные модульные тесты. Это решит Ваши проблемы скорости. Реальные модульные тесты не имеют взаимодействия DB или взаимодействия HTTP.

3
ответ дан 8 December 2019 в 02:53
поделиться

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

2
ответ дан 8 December 2019 в 02:53
поделиться

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

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

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

1
ответ дан 8 December 2019 в 02:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: