Можно ли определить обратный вызов метода, если его тип void и его «return»;пропустил его исполнение? - PullRequest
Новая
       32

Можно ли определить обратный вызов метода, если его тип void и его «return»;пропустил его исполнение?

0 голосов
/ 21 декабря 2011

У меня есть метод, который работает следующим образом: 

public void deploy(UserInput userInput)  {
   if (userInput is wrong)
      return;

   //start deployment process
}

UserInput состоит из отдельных проверок в методе deploy.Теперь я хотел бы протестировать JUnit, если алгоритмы проверки пользовательского ввода ведут себя правильно (поэтому, если процесс развертывания начнется или нет, в зависимости от правильного или неправильного пользовательского ввода).Поэтому мне нужно проверить это с правильным и неправильным пользовательским вводом.Я мог бы выполнить эту задачу, проверив, развернуто ли что-либо вообще, но в этом случае это очень громоздко.Поэтому мне интересно, можно ли как-то узнать в соответствующем тесте JUnit, был ли прерван метод развертывания (из-за неправильного ввода данных пользователем)?(Кстати, изменение метода развертывания не вариант.)

Ответы [ 2 ]

2 голосов
/ 21 декабря 2011

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

public void deploy(UserInput userInput)  {
   if (userInput is wrong)
      return;

   //start deployment process
   startDeploy(); // mock this method
}

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

Альтернатива - интеграционные тесты

Похоже, что метод развертывания является большим и сложным и имеет дело с файлами, файловыми системами, внешними службами (ftp)и т. д.

В долгосрочной перспективе иногда проще просто принять то, что вы имеете дело с внешними системами, и протестировать эти внешние системы.Например, если deploy () копирует файл в каталог x, проверьте, что файл существует в целевом каталоге.Я не знаю, насколько сложное развертывание, но часто издеваться над этими методами может быть так же сложно, как просто тестировать реальное поведение.Это может быть громоздким, но, как и большинство тестов, это позволит вам реорганизовать ваш код, чтобы его было проще понять.Если ваша цель - рефакторинг, то, по моему опыту, рефакторинг проще, если вы тестируете реальное поведение, а не издеваетесь.

0 голосов
/ 21 декабря 2011

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

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

if (_validator.isValid(userInput)) {
  _deployer.deploy(userInput);
}

Таким образом, вы можете легко проверить, что, если валидатор возвращает false, средство развертывания никогда не вызывается (используя насмешку)фреймворк, такой как jMock), и то, что он вызывается, если валидатор возвращает true.

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

...