Как вы говорите, что ваши юнит-тесты верны?

Question

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

Редактировать: Я также понимаю, что вы могли бы написать небольшие, детальные модульные тесты, которые было бы легко понять. Однако, если вы предполагаете, что небольшой гранулярный код безупречен и пуленепробиваем, вы можете просто написать небольшие гранулированные программы и не нуждаться в модульном тестировании.

Edit2: Для аргументов «модульное тестирование предназначено для того, чтобы убедиться, что ваши изменения ничего не нарушают» и «это произойдет только в том случае, если тест имеет тот же недостаток, что и код», что, если тест переходит? С плохим тестом можно пройти как хороший, так и плохой код. Мой главный вопрос в том, что хорошего в модульном тестировании, поскольку, если ваши тесты могут быть ошибочными, вы не сможете реально повысить свою уверенность в своем коде, не сможете доказать, что ваш рефакторинг сработал, и не можете доказать, что вы соответствуете спецификации? 1005 *

Answer 1

Это одно из преимуществ TDD: код выступает в качестве теста для тестов.

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

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

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

Мне действительно нравится, что описание Боба Мартина эквивалентно двойной бухгалтерии.

Answer 2

Вы не можете доказать, что тесты верны, и если вы пытаетесь это сделать, вы делаете это неправильно.

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

Метрика, тем не менее, помогает руководству чувствовать себя лучше, и это иногда полезно само по себе!

Answer 3

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

• Были ли у вас какие-либо дефекты, о которых сообщалось при ручном тестировании, и модульный тест не обнаружил (хотя и был ответственен за это), потому что в вашем тесте была ошибка?
• Были ли у вас ложные негативы в прошлом?
• Достаточно ли просты ваши юнит-тесты?
• Вы пишете их перед новым кодом или хотя бы параллельно?

Answer 4

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

Answer 5

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

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

Answer 6

Как и выше, лучший способ - написать тест перед реальным кодом. Найдите реальные примеры кода, который вы тестируете, если это применимо (математическая формула или аналогичная), и сравните с ним модульный тест и ожидаемый результат.