Важное примечание:
Если вас беспокоит только код C # / .NET и вы хотите запускать только модульные тесты, то эта функция уже существует в Visual Studio 2017 (только для редакции Enterprise) под названием Live Unit Testing, подробнее об этом здесь: https://docs.microsoft.com/en-us/visualstudio/test/live-unit-testing-intro?view=vs-2017
Живое модульное тестирование - это технология, доступная в Visual Studio 2017 версии 15.3, которая автоматически выполняет ваши модульные тесты в режиме реального времени при внесении изменений в код.
Мой оригинальный ответ:
(Раньше я работал в SDE в Microsoft, работая над Visual Studio (2012, 2013 и 2015). Я сам не работал над конвейером сборки, но надеюсь, что смогу кое-что понять:)
Как Visual Studio может автоматически создавать и тестировать код?
Это не так, а , на мой взгляд, , этого не следует, предполагая, что под "сборкой и тестированием кода" вы подразумеваете, что он должен выполнить стандартную сборку проекта и затем запустить тесты.
Eclipse строит только то, что затронуто изменением. Работает как шарм.
Даже инкрементные сборки не являются мгновенными, особенно если есть значительная активность после компиляции (например, сложное связывание и оптимизация (даже в режиме отладки), внешние задачи сборки (например, встраивание ресурсов, сжатие исполняемых файлов, подписывание кода и т. Д.).
В Eclipse, в частности, эта функция не идеальна. Eclipse - это, прежде всего, Java IDE, и в проектах Java вполне возможно быстро выполнить инкрементную сборку очень , поскольку время сборки Java в любом случае очень быстрое, а инкрементная сборка так же проста, как и замена встроенного файла .class в Java .jar. В Visual Studio, для сравнения, время сборки сборки .NET также быстро, но не так просто, поскольку выходной PE (.exe / .dll) файл не так просто перестраивать.
Однако в других типах проектов, особенно в C ++, время сборки намного больше, поэтому не рекомендуется использовать эту функцию для разработчиков на C / C ++, фактически собственная документация Eclipse рекомендует пользователям C / C ++ отключать эту функцию:
https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Ftasks%2Fcdt_t_autobuild.htm
По умолчанию рабочая среда Eclipse настроена на автоматическое создание проектов. Однако для разработки на C / C ++ вы должны отключить эту опцию , в противном случае весь ваш проект будет перестроен всякий раз, когда, например, вы сохраняете изменения в своем make-файле или исходных файлах. Нажмите «Проект»> «Автоматически построить» и убедитесь, что рядом с пунктом меню «Автоматически строить» нет галочки.
Другие типы проектов также не поддерживают эту функцию, например плагин Eclipse для Go:
https://github.com/GoClipse/goclipse/releases/tag/v0.14.0
Изменения в 0.14.0:
[...]
Построитель проектов больше не вызывается, если в рабочей области включен параметр «Автоматически создавать» и файл сохранен. (это все равно считалось ошибочным)
(Это замечание в скобках содержится в списке изменений GoClipse и, безусловно, проясняет мнение авторов плагина об автоматических сборках)
Затем я устанавливаю Infinitest, который автоматически запускает все тесты, затронутые сохраненным изменением.
Visual Studio может запускать ваши тесты после сборки автоматически (но вам все равно нужно запустить сборку самостоятельно), это встроенная функция, см. Здесь:
https://docs.microsoft.com/en-us/visualstudio/test/run-unit-tests-with-test-explorer?view=vs-2017
Чтобы запустить свои модульные тесты после каждой локальной сборки, выберите Test в стандартном меню, а затем выберите Run Tests After Build на панели инструментов Test Explorer.
Что касается моих причин, почему Visual Studio не поддерживает Build-on-Save:
- Только самые тривиальные проекты на C # / VB и TypeScript встраиваются за одну секунду, другие типы проектов, такие как C, C ++, SQL Database и т. Д., Занимают от нескольких секунд для «теплого» перестроения простых проектов - буквально часов для больших - масштабируемые проекты C ++ с большим количеством импортированных заголовков на одноядерном процессоре, малым объемом оперативной памяти и жестким диском со скоростью вращения 5400 об / мин.
- Многие сборки очень интенсивно используют ввод-вывод (особенно проекты на C / C ++ с большим количеством заголовков * cough *, как * cough *), а не с привязкой к процессору, а задержки дискового ввода-вывода являются основной причиной блокировок и замедления в других приложениях, запущенных на компьютере, потому что операция подкачки диска может быть отложена или потому, что они выполняют операции дискового ввода-вывода в потоке графического интерфейса и т. д. - поэтому, если эта функция включена в дисковой IO-сборке, это просто означает, что компьютер будет сильно дрожать каждый раз, когда вы нажимаете Ctrl + S или всякий раз, когда запускается автосохранение.
- Не каждый тип проекта поддерживает инкрементные сборки или может поддерживать быструю инкрементную сборку. Java является исключением из этого правила, потому что Java была разработана таким образом, чтобы каждый входной файл
.java отображал 1-в-1 в выходной файл .class, что делает инкрементные сборки очень быстрыми, так как требуется перестроить только фактически измененный файл, но другие проекты, такие как C # и C ++, не имеют такой роскоши: если вы сделаете даже несущественное 1-символьное редактирование в макросе препроцессора C или шаблоне C ++, вам нужно будет перекомпилировать все остальное, использовавшее этот шаблон, а затем компоновщик и Оптимизатор (если встраивание кода) придется перезапускать - задача не из простых.
- Сборка может включать удаление файлов на диске (например, очистка выходной папки сборки) или изменение состояния вашей глобальной системы (например, запись в журнал сборок не для проекта) - по моему мнению, если программа когда-либо удаляет что-либо под каталог, который я лично владею (например,
C:\git\ или C:\Users\me\Documents\Visual Studio Projects), черт побери, лучше попросить у меня прямого разрешения сделать это каждый раз - особенно если я хочу что-то сделать с последними результатами сборки, пока я над чем-то работаю. Я не хочу сначала копировать результаты сборки в безопасный каталог. По этой же причине команда «Чистый проект» является отдельной и не подразумевается под «Проектом сборки».
- Пользователи часто нажимают Ctrl + S обычно каждые несколько секунд (я один из тех людей) - я нажимаю Ctrl + S , даже когда я написал неполный код в моем редактор: вещи с синтаксическими ошибками или, возможно, даже деструктивным кодом - я не хочу, чтобы этот код создавался вообще, потому что он еще не готов! Даже если в моем коде нет ошибок, IDE не сможет определить мои намерения.
- Сборка проекта - это один из способов получить список ошибок с помощью вашей кодовой базы, но в течение десятилетий в этом не было необходимости: в средах разработки долгое время возникали ошибки и предупреждения во время разработки, не требуя компилятора для запуска сборки (благодаря такие вещи, как Языковые серверы) - на самом деле запуск сборки просто выдаст мне двойные сообщения об ошибках в окне ошибок IDE, потому что у меня уже будут сообщения об ошибках из списка ошибок времени разработки.
- Visual Studio, по крайней мере (я не могу говорить об Eclipse), переходит в особый вид режима только для чтения во время сборки: так что вы не можете сохранять дальнейшие изменения на диск во время сборки, вы можете ' • изменить настройки проекта или IDE и т. д. - это потому, что процесс сборки - это длительный процесс, который зависит от того, находится ли исходный проект в фиксированном, известном состоянии - компилятор не может выполнять свою работу, если исходные файлы находятся изменено, пока он их читает! Таким образом, если среда IDE всегда создавалась (даже хотя бы на несколько секунд) после каждого сохранения, пользователям не понравится, как среда IDE блокирует их от определенных задач редактирования, пока сборка не будет завершена (помните, что среды IDE делают больше, чем просто показывают редакторы: Некоторое специализированное окно инструментов может потребоваться записать в файл проекта, чтобы просто его открыть).
- Наконец, сборка не свободна от побочных эффектов (на самом деле, в этом весь смысл!) - всегда есть риск, что что-то может пойти не так в процессе сборки и сломать что-то еще в вашей системе. Я не говорю, что сборка рискованна, но если у вас есть собственный скрипт сборки, который делает что-то рискованное (например, он запускает
TRUNCATE TABLE CriticalSystemParameters) и сборка прерывается (потому что они всегда так делают), это может привести к тому, что ваша система будет в плохом состоянии. - Кроме того, существует (слегка философская) проблема: «Что произойдет, если вы сохраните неполные изменения в сценарии сборки вашего проекта?».
Теперь я признаю, что некоторые типы проектов создаются очень и очень быстро, например TypeScript, Java и C #, а другие имеют исходные файлы, которые вообще не нуждаются в компиляции и компоновке, и просто запускают инструменты проверки (например, PHP или JavaScript). - и использование Build-on-Save может быть полезно для этих людей, но, возможно, для ограниченного числа людей, чей опыт улучшается, это явно ухудшает его для остальных пользователей.
И если вы действительно хотите построить при сохранении, достаточно просто написать в качестве расширения для Visual Studio (подключите команду «Сохранить файл» и затем вызовите команду «Сборка проекта» в своем обработчике) - или войдите в привычку нажатия Ctrl + B после Ctrl + S :)