Тестирование — отдельная большая тема. Чаще всего под этим подразумевается т.н. юнит-тестирование. Суть идеи легко понять на простом примере. Создавая тест вы пишете некую обёртку, которая выполнит одну из ваших функций и проверит ожидаемый результат. Затем, когда вы поменяете что-либо в другой функции, от которой зависит первая функция, чтобы проверить, что изменение ничего не сломало — вам достаточно запустить созданные ранее тесты. Надеюсь понятно, насколько это может быть полезно в большом проекте.
Кажется, здесь немного искажено понятие юнит-теста. Его суть в проверке одной конкретной функции, на которую пишется тест. Если у этой функции есть другие зависимости, то вместо них желательно «подсунуть» фэйковые реализации — мок или стаб.
Под описание в статье больше подпадает интеграционный тест.
Нет, стэктрейса не было… но как-то сомневаюсь, что выводить его разумно в случае ухода в бесконечную рекурсию — это ж какой объем у него будет. Если по умолчанию максимальный размер стека в 64-битной системе 4 МБ (или 1 МБ для 32-битной системы), и весь этот объем — повторяющийся вызов одной и той же функции.
Тем не менее, в сессии видно, какой именно из тестов упал, в сообщении явно указано про Stack overflow exception — что скорее всего подразумевает рекурсию. В большинстве случаев, на мой взгляд, этого вполне достаточно, чтобы локализовать проблему. Если нет — то видимо, есть проблемы с архитектурой в целом, ИМХО.
Запустил сессию с двумя тестами. В первом — вызов бесконечной рекурсии. Появляется MessageBox с ошибкой «Stack overflow exception occurred in test. Test run is aborted.», соответственно по нему статус Aborted, по второму тесту — Inconclusive (то есть текущая сессия не продолжается). Ничего не упало, решарпер и студия работают стабильно. Все-таки он не «успешно упал», а «успешно поймал» (catch) =)
Самому стало любопытно — проверил. Решарпер успешно поймал исключение и выдал ошибку «Stack overflow exception occurred in test. Test run is aborted.». Если запускал в Test Explorer самой студии (Visual Studio 2015 Enterprise), она тоже удачно справилась и выдала в Output «The test execution process crashed while running the tests.», предложив подебажить с файлом .dmp
Кажется, здесь немного искажено понятие юнит-теста. Его суть в проверке одной конкретной функции, на которую пишется тест. Если у этой функции есть другие зависимости, то вместо них желательно «подсунуть» фэйковые реализации — мок или стаб.
Под описание в статье больше подпадает интеграционный тест.
private string _privateField),public int PublicProperty { get; set; }),int localVariable)Кроме того, следование таким соглашениям улучшает читабельность кода, особенно для новых людей на проекте
Кроме того, при запуске теста в том же Решарпере в режиме дебага он приостанавливает исполнение, как на обычном эксепшне:
Да и студия при запуске тестов сама предлагает подебажить:
Тем не менее, в сессии видно, какой именно из тестов упал, в сообщении явно указано про Stack overflow exception — что скорее всего подразумевает рекурсию. В большинстве случаев, на мой взгляд, этого вполне достаточно, чтобы локализовать проблему. Если нет — то видимо, есть проблемы с архитектурой в целом, ИМХО.
Все-таки он не «успешно упал», а «успешно поймал» (catch) =)