Как преодолеть проблемы регрессии тестового теста ...?

Question

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

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

Unit Test Regression Analysis Tool

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

С благодарностью на продвинутом этапе

Answer 1

Часто проверяйте часто.

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

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

Answer 2

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

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

Anywho, несколько других вещей, которые я видел, что причиной этого:

• Юнит-тесты, как правило, не должны зависеть от более чем класс и метод их тестирования. Посмотрите на зависимости, которые закрались. Убедитесь, что вы используете инъекцию зависимостей, чтобы упростить тестирование.
• Действительно ли это уникальные тесты? Или они испытывают одно и то же снова и снова? Если они всегда будут терпеть неудачу вместе, почему бы просто не удалить все, кроме одного?
• Многие люди предпочитают интеграцию по модульным тестам, так как они получают больше средств для их доллара. Но при этом одно изменение может ломать множество тестов. Может быть, вы пишете интеграционные тесты?
• Возможно, все они проходят через обычный код настройки для множества тестов, что приводит к их разрыву в унисон. Возможно, это может быть издевательствовано, чтобы изолировать поведение.

Answer 3

1. Что касается работы подмножество наиболее вероятного испытания на провал - так как он, как правило, не удается из-за других членов команды (по крайней мере, в моем случае), мне нужно, чтобы просить других, чтобы запустить мой тест - который мог бы быть «политически проблематичным» в некоторых средах разработки;). Любые другие предложения будут назначены. Большое спасибо - SpeeDev 30 сентября '10 в 23:18

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