Могу ли я проверить неудачный тест

Question

Наша команда испытывает жаркие споры относительно того, разрешаем ли мы, чтобы тесты на единичные тесты были проверены на контроль источника.

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

Другая сторона аргумента состоит в том, что эти тесты, если они зарегистрированы, должны быть отмечены атрибутом Игнорировать - аргумент состоит в том, что ночная сборка не должна служить списком TODO для разработчика.

Проблема с атрибутом Ignore заключается в том, что мы склонны забывать о тестах.

Есть ли у сообщества какие-либо советы для нас?

Мы являемся командой из 8 разработчиков с ночной сборкой. Лично я пытаюсь практиковать TDD, но команда имеет тенденцию писать модульные тесты после того, как код написан

Answer 1

Я бы сказал, что не только вы должны не проверить в новых непройденных тестах, вы должны отключить свои «10 или около долгосрочных провала попытки испытаний». Разумеется, лучше исправить их, но каждый раз, когда у вас есть неудачная сборка, и каждый проходящий тест проходит (с некоторыми исключенными) - вам лучше зеленый. Теперь, когда вы меняете то, что вызывает новый провал в вашем существующем наборе тестов, вы, скорее всего, пропустите его.

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

Answer 2

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

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

Очевидно, что вы не используете тесты одинаково, иначе вы даже не спросите.

Answer 3

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

Я думаю, было бы нормально проверить неудачные тесты, если вы обнаружили ошибку и могли бы быстро воспроизвести ее с помощью теста, но код нарушения не является «вашим», и у вас нет времени/ответственности, чтобы получить в него достаточно, чтобы исправить код. Затем дайте билет кому-то, кто знает дорогу и укажет на тест.

В противном случае я бы сказал, что ваша система билетов используется как список TODO, а не сборка.

Answer 4

Если вы использовали DVCS (например, git), это не было бы проблемой, так как вы могли бы выполнить тест на неудачу в своем локальном репозитории, заставить его работать, а затем нажимать на весь лот (тест и исправление) обратно в главный репозиторий команды. Работа выполнена, все счастливы.

Как вам кажется, вы не можете этого сделать, лучше всего убедиться, что тест написан и не работает в вашей песочнице, а затем исправить это до совершения.Это может быть или не быть большим TDD, но это разумный компромисс с практикой работы всех остальных; работая с, ваши сотрудники важнее, чем следовать принципу башни из слоновой кости во всех аспектах, поскольку автор принципа не находится в соседней ячейке ...

Answer 5

Я обсуждал это с другом и нашим первым комментарий был недавним выродком & poke :) (прилагается)

Чтобы быть более конкретным - все тесты должны быть написаны до того, как это было TDD, но те, кто проверяет нереализованную функциональность, должны иметь свое значение, добавленное с отрицанием , Если он не реализован - он не должен работать. [Если это работает - тест плох] После внедрения теста вы удаляете !, и он работает [или не работает, но тогда он должен сделать это :)].

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

Answer 6

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

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

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

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

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

Answer 7

Я вижу, что у вас есть ряд проблем.

1) Вы пишете неудачные тесты.

Это замечательно! Тем не менее, кто-то намеревается проверить тех, кто «фиксируется в текущем спринте». Это говорит мне, что слишком много времени, чтобы пройти те модульные тесты. Либо тесты охватывают более одного или двух аспектов поведения, либо ваш базовый код слишком сложный. Рефакторируйте код, чтобы разбить его и использовать mocks для разделения обязанностей тестируемого класса от его соавторов.

2) Вы склонны забывать о тестах с атрибутами [Игнорировать].

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

3) Ваша команда пишет тесты после написания кода.

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

4) Вы пытаетесь применить TDD.

Сделайте или не делайте. Нет никакой попытки. Сначала напишите тест, или нет. Обучение никогда не останавливается даже тогда, когда вы думаете, что хорошо делаете TDD.