Случайные сбои теста при отправке кода в Jenkins

Я тоже спрашивал об этом раньше, но не удовлетворен ответом.

Что я использую:

  • Работа на сайте Django/python.
  • Разработка выполняется на виртуальных средах Python локально.
  • используя GIT в качестве моего SCM
  • иметь отдельные виртуальные серверы, развернутые для веток Developer и Production для GIT
  • Использование Jenkins CI для непрерывной интеграции. Отдельный виртуальный сервер, развернутый для Jenkins

Работающий:

  • У меня есть модульные тесты, дымовые тесты и интеграционные тесты для веб-сайта. Jenkins настроен так, что всякий раз, когда код переносится из моей локальной ветки git в ветку Developer и Production в репозитории git, в Jenkins запускается сборка.

Проблема:

  • Мои тесты проходят локально, когда я выполняю тест python manage.py.
  • Случайные тесты (в основном модульные тесты) FAIL в Jenkins, когда код передается в другие ветки (Developer и Production).
  • Если после сбоя теста я выполняю сборку вручную, нажимая кнопку «Построить сейчас» в Jenkins, тесты обычно проходят успешно, и сборка завершается успешно.
  • Иногда, когда в код не вносятся изменения, а код по-прежнему отправляется в эти ветки, тесты в Jenkins случайно не проходят.

Некоторые распространенные ошибки:

  • Ошибка утверждения: 302! = 200
  • TypeError: объект «NoneType» не подлежит подписке
  • IndexError: индекс списка вне допустимого диапазона
  • AssertionError: datetime.datetime(2012, 12, 5, 0, 0, 27, 218397)! = datetime.datetime(2012, 12, 5, 0, 0, 27, 239884)
  • AssertionError: ответ перенаправлен на «x», ожидаемый «y»

Устранение неполадок на сегодняшний день:

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

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

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


python django jenkins django-testing django-jenkins
person SaurabhM    schedule 04.01.2013    source источник
comment
Можете ли вы связать свой другой вопрос, который вы разместили?   -  person Tommaso Barbugli    schedule 05.01.2013
comment
Предыдущий вопрос   -  person SaurabhM    schedule 07.01.2013
comment
Дженкинс может изменить порядок выполнения ваших тестов. Если ваши тесты не являются юнит-тестами, возможно, что-то сохраняется между тестами, вызывая эти проблемы.   -  person Ian Stapleton Cordasco    schedule 08.01.2013
comment
Я получаю точно такую ​​​​же проблему. Как вы это решили?   -  person chhantyal    schedule 19.09.2013

Ответы (2)


arrow_upward
1
arrow_downward

Это действительно сложный вопрос.

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

В остальном это обычная отладка:

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

  2. Получите больше информации. Утверждения могут быть сделаны для печати пользовательского сообщения, когда они терпят неудачу. Вывести значения соответствующих переменных. Добавляйте отладочные распечатки в свой код и тесты. Посмотрите, где все не так, как должно быть. Погуглите, как пользоваться отладчиком Python.

Сохраняйте непредвзятость. Ошибка может быть где угодно: в оборудовании, в программной среде, в вашем коде или в тестовом коде. Но если вы не Бог, Линус Торвальдс или Брайан Керниган, это безопасная первая гипотеза, что ошибка возникает где-то между вашей клавиатурой и спинкой вашего сиденья. (И все три вышеперечисленных хакера тоже допустили серьезные ошибки.)

person sti    schedule 07.01.2013

arrow_upward
-1
arrow_downward

Для проблемы - AssertionError: datetime.datetime(2012, 12, 5, 0, 0, 27, 218397) != datetime.datetime(2012, 12, 5, 0, 0, 27, 239884)

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

пример:

from freezegun import freeze_time
import datetime
import unittest


@freeze_time("2012-01-14")

def test():

assert datetime.datetime.now() == datetime.datetime(2012, 1, 14)
person Ashis Kar    schedule 25.01.2018