Должны ли неудачные тесты привести к сбою при непрерывной сборке?

Question

Если у вас есть проект, у которого есть тесты, которые выполняются как часть процедуры сборки на компьютере сборки, если набор тестов не пройден, должна ли вся сборка быть неудачной?
Что нужно учитывать при ответе на этот вопрос? Имеет ли значение, какие тесты не пройдены?

---

Справочная информация, которая вызвала этот вопрос:

В настоящее время я работаю над проектом, в котором есть NUnit тестов, которые выполняются как часть процедуры сборки и выполняются на нашей машине круиз-контроля .net .

Раньше проект настраивался таким образом, что при сбое каких-либо тестов сборка завершается неудачно. Причина в том, что если тесты не пройдены, это означает, что продукт не работает / не завершен / это провал проекта, и, следовательно, сборка должна завершиться неудачей.

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

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

Answer 1

Если это каким-либо образом выполнимо, то сделайте это. Это значительно уменьшает проблему разбитого окна :

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

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

Поэтому вы всегда должны стремиться к тому, чтобы все работали (а не только "большинство из них"). И рассмотрение каждого неудачного теста как причины неудачной сборки ведет к достижению этой цели.

Answer 2

Если модульный тест не пройден, некоторый код работает не так, как ожидалось. Так что код не должен быть выпущен.

Хотя вы можете сделать сборку для целей тестирования / исправления ошибок.

Answer 3

Если вы считаете, что дело было достаточно важным, чтобы написать тест, то если этот тест не пройден, значит, программное обеспечение не работает. Исходя из этого, да, он должен считать сборку неудачной, а не продолжать. Если вы не используете эти рассуждения, то кто решает, какие тесты не важны? Где грань между «если это не удастся, то это нормально, а если это не удастся, то это не так»? Ошибка - это ошибка.

Answer 4

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

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

Представьте, что один из членов вашей команды вносит ошибку в код, который покрывает один модульный тест (который всегда терпит неудачу). Тест не будет обнаружен, поскольку вы допускаете, что один тест всегда будет неудачным.

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

Answer 5

Все ответы были отличными, вот что я решил сделать:

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

• Сборка может дать сбой, если какие-либо тесты не пройдут, что приведет к снижению запаха
• Тесты, которые игнорируются, должны быть защищены руководителем проекта (кто бы ни отвечал)
• Все игнорируемые тесты помечаются особым образом

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

---

Что я на самом деле сделал: исправил сломанные тесты.

Answer 6

Настоящая проблема в ваших неудачных тестах. У вас не должно быть модульного теста, когда все в порядке, чтобы провалиться, потому что это крайний случай. Решите, важен ли крайний случай или нет - если нет, то удалите модульный тест; если да, то исправьте код.

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

Answer 7

На мой взгляд, это действительно зависит от ваших юнит-тестов, ... если ваши юнит-тесты действительно являются тестами UNIT (как они должны быть => "ссылка на бесконечные книги;)") тогда сборка должна завершиться сбоем, потому что что-то ведет себя не так, как должно ...

но чаще всего (к сожалению, часто встречаемому), во многих проектах эти модульные тесты охватывают только некоторые «ребра» и / или являются интеграционными тестами, сборка должна продолжаться (да, это субъективный ответ;)

короче: Знаете ли вы, что юнит-тесты в порядке: провал; еще: построить на