Как Вы говорите, что Ваши модульные тесты корректны?

Модульный тест должен выразить "контракт" того, что Вы тестируете. Это - более или менее спецификация единицы, помещенной в код. По сути, учитывая спецификации, должно быть более или менее очевидно, "корректны" ли модульные тесты.

, Но я не волновался бы слишком много о "правильности" модульных тестов. Они - часть программного обеспечения, и как таковой, они могли быть неправильными также. Точка модульных тестов - от моего POV - то, что они удостоверяются, что "условия" контракта" Вашего программного обеспечения не нарушены случайно . Именно это делает модульные тесты настолько ценными: можно вырыть вокруг в программном обеспечении, осуществить рефакторинг некоторые части, изменить алгоритмы в других, и модульные тесты скажут Вам при повреждении чего-нибудь. Даже неправильный модульные тесты скажут Вам это.

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

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

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

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

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

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

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

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

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

мне действительно нравится описание Bob Martin этого как являющегося эквивалентным двойной бухгалтерии.

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

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

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

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

, Как знать, хороши ли мои модульные тесты?

Вы не можете протестировать логический период части! Если в Вашем коде говорится, что 2+2 = 5 и Ваш тест удостоверяется, что 2+2 = 5 затем для Вас 2+2 5. Для записи хороших модульных тестов, у Вас ДОЛЖНО быть хорошее понимание домена, с которым Вы работаете. То, когда Вы знаете то, что Вы пытаетесь выполнить Вас, запишет хорошие тесты и хороший код для выполнения его. Если у Вас есть много модульных тестов, и Ваши предположения являются неправильными затем рано или поздно, что Вы узнаете свои ошибки.

1. сложность из кода модульного теста (или должен быть), меньше (часто порядки величины меньше), чем реальный код
2. шанс Вашего кодирования ошибки в Вашем модульном тесте, который точно соответствует ошибке в Вашем реальном коде, намного меньше, чем просто кодирует ошибку в Вашем реальном коде (если Вы кодируете ошибку в своем модульном тесте, который не соответствует ошибке в Вашем реальном коде, который это должно привести к сбою). Конечно, при создании неправильных предположений в реальном коде, Вы, вероятно, сделаете то же предположение снова - хотя набор ума поблочного тестирования должен все еще уменьшить даже, что случай
3. Как уже сослался на, когда Вы пишете модульный тест, Вы имеете (или должен иметь), другой набор ума. При написании реального кода Вы думаете, "как я решаю эту проблему". При записи модульного теста Вы думаете, "как я тестирую каждый возможно способ, которым это могло повредиться"

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

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

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

Или Вы могли записать тесты для своих модульных тестов... :P

Ну, Dijkstra заметно сказал:

"Тестирование показывает присутствие, не отсутствие ошибок"

IOW, как Вы записали бы, модульный тест на функцию добавляют (интервал, интервал)?

IOW, это - жесткое.

Чтобы это было проблемой, Ваш код должен будет быть багги способом, который по совпадению заставляет Ваши тесты передавать. Это недавно произошло со мной, где я проверял, что данное условие (a) заставило метод перестать работать. Тест передал (т.е. отказавший метод), но он передал, потому что другое условие (b) вызвало отказ. Запишите свои тесты тщательно и удостоверьтесь, что модульные тесты тестируют ОДНУ вещь.

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

Существует два способа помочь гарантировать правильность Ваших модульных тестов:

• TDD: Запишите тест сначала, затем напишите код, который он предназначен для тестирования. Это означает, что Вы добираетесь до , см. их сбой. Если Вы знаете, что это обнаруживает по крайней мере приблизительно классы ошибок (такие как, "Я не реализовал функциональности в функции, которую я хочу протестировать все же"), то Вы знаете, что это не абсолютно бесполезно. Это может все еще позволить некоторым другим ошибкам проскользнуть, но мы знаем, что тест не полностью неправильный.
• Имеют много тестов. Если один тест позволит некоторым ошибкам проскользнуть, то они, скорее всего, вызовут ошибки далее по линии, заставляя другие тесты перестать работать. Поскольку Вы замечаете, что, и исправляют незаконный код, Вы получаете шанс исследовать, почему первый тест не зафиксировал ошибку как ожидалось.

И наконец, конечно, сохраняют модульные тесты столь простыми, что они вряд ли будут содержать ошибки.

У меня был тот же вопрос, и прочитав комментарии, вот что я теперь думаю (с должным уважением к предыдущим ответам):

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

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

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

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

Если вы ДЕЙСТВИТЕЛЬНО захотели применить второй уровень модульного тестирования, чтобы доказать правильность своих модульных тестов, вы могли бы это сделать, но это может привести к уменьшению отдачи. Чтобы взглянуть на это ложно-численно:

Предположим, что модульное тестирование снижает количество производственных ошибок на 50%. Затем вы пишете мета-модульные тесты (модульные тесты для поиска ошибок в модульных тестах). Скажите, что это обнаруживает проблемы с вашими модульными тестами, уменьшая количество ошибок в производстве до 40%. Но на написание мета-модульных тестов ушло 80% времени, как на написание модульных тестов. На 80% усилий вы получаете только 20% прироста. Возможно, написание мета-мета-модульных тестов даст вам еще 5 процентных пунктов, но теперь опять же на написание мета-модульных тестов ушло 80% времени, поэтому для 64% усилий по написанию модульных тестов (которые дали вам 50%) у вас еще 5%. Даже при значительно более либеральных цифрах это неэффективный способ тратить ваше время.

В этом сценарии ясно, что выход за рамки написания модульных тестов не стоит затраченных усилий.

снижение количества ошибок в производстве до 40%. Но на написание мета-модульных тестов ушло 80% времени, как на написание модульных тестов. На 80% усилий вы получаете только 20% прироста. Возможно, написание мета-мета-модульных тестов даст вам еще 5 процентных пунктов, но теперь опять же на написание мета-модульных тестов ушло 80% времени, поэтому для 64% усилий по написанию модульных тестов (которые дали вам 50%) у вас еще 5%. Даже при значительно более либеральных цифрах это неэффективный способ тратить ваше время.

В этом сценарии ясно, что выход за рамки написания модульных тестов не стоит затраченных усилий.

снижение количества ошибок в производстве до 40%. Но на написание мета-модульных тестов ушло 80% времени, как на написание модульных тестов. На 80% усилий вы получаете только 20% прироста. Возможно, написание мета-мета-модульных тестов даст вам еще 5 процентных пунктов, но теперь опять же на написание мета-модульных тестов ушло 80% времени, поэтому для 64% усилий по написанию модульных тестов (которые дали вам 50%) у вас еще 5%. Даже при значительно более либеральных цифрах это неэффективный способ тратить ваше время.

В этом сценарии ясно, что выход за рамки написания модульных тестов не стоит затраченных усилий.

Возможно, написание мета-мета-модульных тестов даст вам еще 5 процентных пунктов, но теперь опять же на написание мета-модульных тестов ушло 80% времени, поэтому для 64% усилий по написанию модульных тестов (которые дали вам 50%) у вас еще 5%. Даже при значительно более либеральных цифрах это неэффективный способ тратить ваше время.

В этом сценарии ясно, что выход за рамки написания модульных тестов не стоит затраченных усилий.

Возможно, написание мета-мета-модульных тестов даст вам еще 5 процентных пунктов, но теперь опять же на написание мета-модульных тестов ушло 80% времени, поэтому для 64% усилий по написанию модульных тестов (которые дали вам 50%) у вас еще 5%. Даже при значительно более либеральных цифрах это неэффективный способ тратить ваше время.

В этом сценарии ясно, что выход за рамки написания модульных тестов не стоит затраченных усилий.

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

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

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