Лучшие практики для тестирования других тестов?

Question

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

«Тестовые тесты» могут показаться глупыми, но я хотел знать, есть ли люди, практикующие это, и есть ли какие-либо известные передовые методы для «Тестовых тестов»

Answer 1

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

Существуют инструменты, позволяющие сделать это автоматически и измерить охват тестов, посмотрев, какие мутации вы можете сделать с кодом, который не являетсяпойман тестом.См. Mutation Testing .

Если ваши тесты сложные, вы должны провести их рефакторинг и выделить некоторые сложности в помощники по тестированию.При наличии достаточного количества из них вы можете создать нечто, похожее на тестовую среду, и , который заслуживает тестов.Действительно, JUnit, RSpec, Cucumber, FitNesse и т. Д. - все это тестовые фреймворки и наборы тестов для тестирования фреймворка.

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

Answer 2

Big tests have little tests upon their backs to verfy'em.
And Little tests have lesser tests, and so ad infinitum.

По мотивам стихотворения Джонатана Свифта

Answer 3

Вы затронули несколько вещей здесь. Позвольте мне попытаться охватить их всех ...

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

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

Вам следует формализовать процесс тестирования. Наличие плана тестирования (даже если это просто список сценариев с шагами воспроизведения в вики) - это огромный шаг вперед по сравнению с тем, что большинство людей в своих усилиях по тестированию. У вас также должна быть некоторая форма проверки кода для тестов до / после их проверки в хранилище кода. Это поможет поймать небольшие ошибки типа: «О ... вы не понимали, что когда x истинно, то всегда возвращает пять?»

Когда тест не пройден, тестер должен проверить, является ли тест правильным. (Часто, потому что это первое, на что разработчик будет настаивать, что тест неверен, а их код верен.) Поглотите свою гордость и убедитесь, что тест на 100% верен, затем попытайтесь выяснить, есть ли ошибка в код доставки. Вы используете программное обеспечение для отслеживания ошибок, верно? Когда тест не пройден, регистрируется ошибка, не так ли? Совместное использование этих тестовых ошибок помогает каждому научиться быть лучшими тестерами.

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

Answer 4

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

В любом случае, это, вероятно, пустая трата времени ..:)

Answer 5

Не тестируйте тесты.Просто предположите, что они верны, и двигайтесь дальше.

Если более низкие тесты не пройдены, конечно, более высокие тесты не пройдут.Это понятно.(Я бы посоветовал сделать пометку «Этот тест основан на прохождении теста X, Y и Z.», если он не интуитивно понятен из-за краткого обзора теста более высокого уровня.)другой тест работает, прежде чем вы продолжите - набор тестов должен запускать ВСЕ тесты.