Инструменты, подобные Pex , могут быть здесь полезны; он разработан, чтобы попытаться найти значения / сценарии, которые приводят к сбою кода (путем проверки каждой ветви кода и вероятного случая ошибки, например, div-by-zero / overflow / и т. д.) на основе статического анализа того, что он делает. Он успешно обнаружил некоторые крайние случаи в коде, такие как .NET "resx" reader.

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

Итак, представьте себе тест, проверяющий, есть ли файл удаляется; вы можете удалить всю папку, и она вернет истину.

Эта форма тестирования, возможно, интересна, но потенциально имеет сомнительную ценность.

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

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

В любом случае интересно подумать.

В подкасте Скотта Хансельмана «Искусство модульного тестирования с Роем Ошеровым» Скотт говорит, что он склонен писать положительные тесты, когда он создает приложение с использованием TDD, и отрицательные тесты после кода. написан для улучшения покрытия кода.

Рой Ошеров говорит, что отрицательные тесты вначале не добавляют ценности; вы не можете пойти к своему боссу и сказать: «Послушайте, вот все, что код НЕ будет делать!»

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