Я понимаю, что одним из основных преимуществ модульных тестов является то, что изменения кода, которые нарушают, очень хорошо видны сразу после критического изменения. Это касается почти любого кода всех видов. Казалось бы, даже для самих тестов. Должен ли я затем писать тесты, чтобы проверить, что мои тесты успешно проверяются? Поскольку это неотъемлемо рекурсивно, как узнать, когда остановиться?Должен ли я писать тесты на тесты?
Должен ли я тогда писать тесты, чтобы проверить, что мои тесты
Нет. Есть вещи, которые вы можете сделать, которые помогут вам, как правило, в сторону действительных испытаний.
Если вы в буквальном смысле написать тест первый - и, таким образом, выходит из строя, когда вы пишете целевой код и тест пройден - вы знаете, это был код под тест, который вызвал прохождение теста.
Если вы тестируете и записываете постепенно, тестирование эволюционирует в более простых и более коротких шагах, которые в совокупности будут иметь тенденцию быть правильными.
Тестирование и тестируемый код, как правило, несколько взаимно подтверждают, если имеется разумное покрытие. Если ваши тесты терпят неудачу, если они ожидаются и проходят, когда они ожидаются; если тесты имеют разумную ширину - покрывают крайние случаи - и они работают так, как ожидалось.
Ditto for depth. Хорошо протестированный код «low level/core» означает, что интуитивно, что код высокого уровня может иметь меньше и проще тестов, чем вы могли бы ожидать.
Assert Исходные условия помогают обеспечить правильное тестовое состояние. Например, процедура Sort: я проверю, что список изначально не отсортирован. Если это отсортировано после, я знаю, что это сработало.
Если вы выведете сообщение об ошибке тестирования: «Неверный ответ. IsTestingUseful был« false », ожидаемый« false »- oops. что-то не выглядит прямо здесь.
В тестовой инфраструктуре может быть значение для ввода тестов. Например, если я пишу структуру тестирования, я, очевидно, хочу проверить некоторые утверждения об этом:
И так далее. Тем не менее, я не вижу смысла в написании тестов более высоких и более высоких заказов-тестов, как правило, небольших, так что они могут изолировать друг от друга более сложные взаимодействия среди компонентов во всей системе.
Я бы пообещал, что усилия программиста, необходимые для выявления и исправления теста на отслаивание, значительно ниже, чем написание тестов для тестов.
Извините, я спрашивал о тестировании фрагмента кода, который составляет тест, нет инфраструктуры тестирования. – Shelvacu
@Shel: Вот что я пытался рассмотреть в последней части моего ответа. Написание автоматических тестов для тестов не так полезно, потому что они маленькие и изолированы и редко даже параметризованы. Они ломаются намного реже, чем код продукта, поэтому для человека хорошо отслеживать неправильные тесты по мере необходимости. –
Существует одна возможная стратегия тестирования тестов: добровольно вводите ошибки в код и проверяйте, обнаруживает ли набор тестов ошибку или нет - эта техника обычно называется мутационным тестированием.
Например, основа может изменить целевой код (один испытывается модульных тестов), как изменение некоторых + в - или какой-то логично и в логические или, и т.д ...
Эта стратегия будет определить, имеют ли тесты достаточный охват, а не в терминах тестируемой функции, строки кода, блока кода или MC-DC, а скорее семантически.
Примером такой структуры для Smalltalk является MuTalk см. https://code.google.com/p/mutalk/, но я уверен, что эквивалентные рамки существуют для других языков - см. Страницу wikipedia https://en.wikipedia.org/wiki/Mutation_testing.
Но в таком случае вы действительно не пишете тесты для тестирования тестов, вы используете структуру для анализа полноты тестов.
Я бы сказал, что если ваш тестовый код устройства достаточно сложный, чтобы вы подумали, что он нуждается в тестировании, тогда ваш тест делает слишком много, поэтому, вероятно, недостаточно конкретный, или ваш код не написан правильно, чтобы сделать его легко проверяемый. – Rhumborl