Vstest.console.exe выходит с кодом 255 в бамбука

Question

Мы выполняем автоматические модульные тесты в нашей сборке Bamboo, но иногда они дают сбой, даже если наш журнал показывает, что все тесты прошли успешно. Я немного погуглил и в настоящее время никуда не деться. Кто-нибудь знает, почему VSTest.Console.Exe возвращает значение, отличное от 0?

Благодаря тонну!

Вот последние несколько строк журнала:

build   26-May-2016 14:11:25    Passed   ReInitializeConnection
build   26-May-2016 14:11:25    Passed   UserIdentifier_CRUD
build   26-May-2016 14:11:25    Results File: D:\build-dir\AVENTURA-T2-COREUNITTESTS\TestResults\bamboo_svc_BUILDP02 2016-05-26 14_10_58.trx
build   26-May-2016 14:11:25    
build   26-May-2016 14:11:25    Total tests: 159. Passed: 159. Failed: 0. Skipped: 0.
build   26-May-2016 14:11:25    Test Run Successful.
build   26-May-2016 14:11:25    Test execution time: 27.3562 Seconds
simple  26-May-2016 14:11:32    Failing task since return code of [C:\Program Files\Bamboo\temp\AVENTURA-T2-COREUNITTESTS-345-ScriptBuildTask-2971562088758505573.bat] was 255 while expected 0
simple  26-May-2016 14:11:32    Finished task 'Run vstest.console.exe' with result: Failed

Answer 1

Это не то решение, которое я хотел, но оно предотвращает сбой моей сборки, если код возврата отличается от 0, и все тесты проходят. В конце нашей тестовой команды я добавляю:

if %ERRORLEVEL% NEQ 0 (
   echo Failure Reason Given is %errorlevel%
   exit /b 0
)

Все это делает так, чтобы он улавливал ошибку, исходящую из vstest.console.exe, и выбрасывал код возврата 0 вместо 255. Если кто-нибудь когда-нибудь выяснит это, я был бы очень признателен, зная, почему код возврата отличается от 0.

Answer 2

Как указано в комментарии к вопросу, я столкнулся с проблемой автоматизации тестирования и для моей компании.

В нашем случае vstest вернет 1, если тесты не пройдены, но иногда вернет 255. В случае возврата 255 тестовый вывод TRX не будет сгенерирован.

В нашей ситуации мы запускаем интеграционные тесты, которые порождают дочерние процессы. К дочерним процессам прикреплены выходные обработчики, которые записывают в тестовый контекст. Тест запускает процесс, затем использует WaitForExit(int milliseconds) метод, чтобы ждать его завершения.

Обработчики вывода на выходе процесса затем выполняются в другом потоке, но имеют ссылку на контекст теста для записи своего вывода.

Это может вызвать проблемы двумя способами:

1. В документации для WaitForExit(int milliseconds) на MSDN говорится:

   Когда стандартный вывод был перенаправлен на асинхронные обработчики событий, возможно, что обработка вывода не будет завершена, когда этот метод вернется. Чтобы убедиться, что асинхронная обработка событий завершена, вызовите перегрузку WaitForExit(), которая не принимает никаких параметров после получения истины от этой перегрузки.

   Это означает, что возможно, что обработчики вывода записывают в контекст после завершения теста.

2. По истечении времени ожидания процесс продолжает выполняться в фоновом режиме и, следовательно, может также выполнять запись в контекст теста.

Исправление в нашем случае было тройным:

1. После звонка WaitForExit(int)либо убить процесс (тайм-аут), либо вызвать WaitForExit() снова (без тайм-аута).
2. Отмена регистрации выходных обработчиков событий из объекта процесса
3. Распоряжаться Process объект правильно (с using).

Специфика вашего случая может отличаться от нашей, но ищите многопоточные тесты, в которых (a) поток может выполняться после завершения теста и (b) записывает результаты теста.