Модульное тестирование и утверждение для пустого метода

Question

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

Это метод:

public void setPersonObj(Person typeObj)
{
    this.typeObj = typeObj;
    createMain();
}

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

Большое спасибо

Answer 1

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

Способ тестирования этих побочных эффектов зависит от используемой вами технологии и подхода к тестированию:

• , еслиметод вызывает некоторых других соавторов / объектов, mock их и впоследствии проверяет mocks

• , если изменяет состояние некоторых других компонентов (добавление элементадля сбора, изменения поля) запрос и утверждения их

• , если хранит что-то на диске / базе данных, запросите их также

• , если в Swing отображается какое-то окно, вам нужно использовать Swing тестовые фреймворки, такие как Window Licker

• , если ...Вы могли бы предоставить более технические подробности ?

КСТАТИ Сеттер, который выполняет некоторую дополнительную несвязанную логику, - это запах кода.Людям, поддерживающим такой код, будет очень трудно понять, что этот невинный setPersonObj() делает что-то кроме ... установки.

Также все эти имена: Person, PersonObj и typeObj должны бытьто же самое для согласованности и совместимости со спецификацией JavaBean.

Answer 2

При юнит-тестировании в принципе есть две разные философии.

• Проверка состояния вашего класса. Обычно вы запускаете метод, который хотите протестировать, и проверяете, что тестируемый класс имеет правильное состояние после запуска, используя для него методы getter или значение, возвращаемое самим методом. В этом сценарии может быть немного сложно протестировать метод void, так как вы можете быть вынуждены добавлять геттеры только для вашего теста, и это нарушит инкапсуляцию. Так что не делай этого. Альтернативным способом является использование классов-заглушек с захватом состояний в качестве ваших зависимостей, но это может быть подозрительно, так как ваши заглушки сами содержат некоторую непроверенную логику.

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

Answer 3

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

Ваш модульный тест также может проверить, установлено ли поле typeObj (вызвав соответствующий метод получения).