Как написать «грязные» модульные тесты?

Question

Я читаю Код Завершен. В этой книге Стив Макконнелл предупреждает, что «тесты для разработчиков, как правило,« чистые тесты ». Разработчики склонны тестировать, работает ли код (чистый тест), а не тестировать все способы разрыва кода (грязные тесты) ».

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

Answer 1

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

Что такое ИМХО, важно понимать, что два мыслительных процесса очень разные. Когда разработчик пишет код в режиме TDD, он стремится сосредоточиться на различных битах функциональности для реализации в коде, а тесты доказывают, что этот и этот бит функциональности или использования используются как указано. Тесты, созданные таким образом, - это то, что Макконнелл называет «чистыми тестами».

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

Все это приводит к важным вопросам: Как ваш метод обрабатывает такие грязные случаи? Должен ли он упасть? Выбросить исключение? Продолжайте как можно лучше? Вернуть код ошибки? Записать отчет об ошибке? ... Все эти небольшие или более крупные решения на самом деле очень важны для правильного и последовательного определения контракта метода или API.

Кент Бек рассказывает о переключении между «шляпой разработчика» и «тестером» в том же смысле. Свободно переключающие точки зрения и мыслительные процессы таким образом требуют практики и опыта.

Answer 2

Какой автор, скорее всего, означает clean test - это тест, который проверяет только happy path выполнения метода.

Тестирование счастливой дорожки, как правило, проще всего, и люди склонны думать, что с это работает, их работа с письменными испытаниями выполнена. Это редко бывает. Рассмотрим:

public void SaveLog(string entry) 
{ 
    var outputFile = this.outputFileProvider.GetLogFile(); 
    var isValid = this.logValidator.IsValid(outputFile); 
    if (isValid) 
    { 
     this.logWriter.Write(outputFile, entry); 
    } 
} 

Удачного тестирования путь будет просто предполагая, все зависимости (outputFileProvider, logValidator, logWriter) работал и писать действительно происходит. Тем не менее, есть большой шанс что-то может сломаться по пути, и те пути тоже должны быть протестированы.Как:

• outputFileProvider не может получить выходной файл
• outputFile оказывается недействительным
• logValidator терпит неудачу со своим исключением
• logWriter не в состоянии написать

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

Answer 3

Элизабет Хендриксон, из Test Obsessed, имеет Test Heuristics Cheat Sheet, в котором она перечисляет всякие испытательных подходов. Документ в целом посвящен тестированию, но в разделе под названием «Атаки типа данных» имеется множество конкретных примеров, на которые могли бы рассчитывать модульные тесты «несчастливый путь».

Например, вот ее идеи о путях, чтобы проверить пути и файлы:

Long Name (> 255 символов)
специальные символы в имени (пространство */\ | <>, (?.) [] {};: ' « @ # $%^&)
несуществующие
уже существует
Нет пространство
минимального пространства
Write-Protected
Недоступно
Locked
На удаленной машине
Corrupted

!