Как преодолеть проблемы регрессии модульного теста ...? - PullRequest
4 голосов
/ 22 сентября 2010

Я искал какое-то решение для групп разработчиков программного обеспечения, которые тратят слишком много времени на решение проблем регрессии модульных тестов (в моем случае это примерно 30% времени !!!), т. Е. На решение проблем с модульными тестами изо дня в день.

Ниже приводится одно знакомое мне решение, которое анализирует, какое из последних изменений кода привело к сбою определенного модульного теста:

Инструмент регрессионного анализа модульных тестов

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

Спасибо за продвинутый

Ответы [ 3 ]

3 голосов
/ 22 сентября 2010

У вас есть наше сочувствие. Похоже, у вас синдром хрупкого теста . В идеале, одно изменение в модульном тесте должно нарушать только один тест - и это должно быть реальной проблемой. Как я уже сказал «в идеале». Но этот тип поведения распространен и поддается лечению.

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

Во всяком случае, несколько других вещей, которые я видел, вызывают это:

  • Юнит-тесты обычно не должны зависеть от класса и метода, который они тестируют. Ищите зависимости, которые закрались. Убедитесь, что вы используете внедрение зависимостей, чтобы упростить тестирование.
  • Это действительно уникальные тесты? Или они проверяют одно и то же снова и снова? Если они всегда собираются потерпеть неудачу вместе, почему бы просто не удалить все, кроме одного?
  • Многие люди предпочитают интеграцию, а не модульные тесты, так как они получают больше страховки за свои деньги. Но при этом одно изменение может сломать множество тестов. Может быть, вы пишете интеграционные тесты?
  • Возможно, они все выполняют какой-то общий код настройки для множества тестов, что приводит к их разрыву в унисон. Может быть, это можно смоделировать, чтобы изолировать поведение.
2 голосов
/ 18 января 2011
  1. Что касается выполнения подмножества наиболее вероятных тестов, которые не пройдены - поскольку обычно это не удается из-за других членов команды (по крайней мере, в моем случае), мне нужно попросить других выполнить мой тест - что может«политически проблематичный» в некоторых средах разработки;).Любые другие предложения будут оценены.Большое спасибо - SpeeDev 30 сентября 2010 г. в 23: 18

Если вам нужно «попросить других» выполнить ваш тест, то это говорит о серьезной проблеме сваша тестовая инфраструктура. Все тесты (независимо от того, кто их написал) должны запускаться автоматически.Ответственность за исправление неудачного теста должна лежать на лице, совершившем изменение, а не на авторе теста.

2 голосов
/ 22 сентября 2010

Тестируйте часто, совершайте часто.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...