Модульное тестирование: достаточно ли хорошо?

Question

У меня есть модульный тест, который может самопроизвольно провалиться 1 раз в 1 000 000 (угадывание) раз, даже если в коде нет ошибок.Является ли это приемлемой терпимостью или манифест TDD требует железной кулачной абсолютности?

Answer 1

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

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

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

Answer 2

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

Лично я бы сказал, что если это действительно 1 на миллион, и вы знаете, почему это происходит, то добавьте комментарий на этот счет и не беспокойтесь об этом. В конце концов, вряд ли это будет беспокоить людей в непрерывном построении. Конечно, если это действительно один из десяти или что-то в этом роде, это совсем другое дело.

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

Answer 3

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

Настоящая проблема, если она не устранена, психологическая. Этот метод будет обвиняться всякий раз, когда в системе происходит что-то странное / случайное / необъяснимое. Лучше починить красную сельдь сейчас, когда вы об этом думаете.

И к вашему сведению, случайность не подразумевает уникальность .

Answer 4

Вы обязательно должны использовать случайные данные? Вы тестируете систему, которая предназначена для возврата двух разных случайных значений? В противном случае создайте заглушку. Модульные тесты должны быть на 100% повторяемыми, это трудно сделать, например, при использовании потоков файловой системы, но для этого нужны заглушки.

Answer 5

Каково ваше требование относительно того, как часто, прежде чем эта ошибка должна произойти?

Вам удобно, и ваши функциональные пользователи, с тем, что происходит?

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

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

Answer 6

Ваш тест утверждает, что stuff1 никогда не равен stuff2, но иногда провал теста означает, что это не так.

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

Возможно, вам будет лучше:

stuff = 4
stuff2 = 5
assert(stuff != stuff2)

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