Scala, Specs2, Mockito и нулевые возвращаемые значения

Если вы его не видели, вы можете посмотреть страница фиктивных ожиданий документации spec2.

В вашем коде заглушка должна быть mockParser.parse(file) returns myResult

Отредактировано после редактирования Дона:

Произошло недоразумение. То, как вы делаете это во втором примере, является хорошим, и вы должны сделать то же самое в первом тесте:

val file = mock[File]
val myType1 = mock[MyType1]

mockParser.parse(file) returns (Some(myType1))
myComponent.process(file)
there was one(mockParser).parse(file)

Идея юнит-тестирования с моками всегда одна и та же: объясните, как работают ваши моки (заглушки), выполните, проверьте.

Это должно ответить на вопрос, теперь личный совет:

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

В вашем примере метод process должен «переводить вещи», поэтому ваши модульные тесты должны быть сосредоточены на нем: издеваться над вашими парсерами и трансляторами, заглушать их и проверять только результат всего процесса. Это менее мелкое зерно, но цель модульного теста не в том, чтобы проверять каждый шаг метода. Если вы хотите изменить реализацию, вам не нужно изменять кучу модульных тестов, проверяющих каждую строку метода.

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

Что мне нужно было сделать, так это предоставить разумное возвращаемое значение по умолчанию для макета в форме org.mockito.stubbing.Answer<T> с типом возвращаемого значения T.

Я смог сделать это со следующей макетной настройкой:

val defaultParseResult = new Answer[Option[MyType1]] {
  def answer(p1: InvocationOnMock): Option[MyType1] = None
}
val mockParser = org.mockito.Mockito.mock(implicitly[ClassManifest[Parser]].erasure,
                         defaultParseResult).asInstanceOf[Parser]

после небольшого просмотра источника для признака org.specs2.mock.Mockito и вещей, которые он вызывает.

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

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

Я не смог найти поддержку более короткого способа сделать это в org.specs2.mock.Mockito, но, возможно, это вдохновит Эрика на его добавление. Приятно, что автор в разговоре...

Изменить

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

def mock[T, A](implicit m: ClassManifest[T], a: org.mockito.stubbing.Answer[A]): T = org.mockito.Mockito.mock(implicitly[ClassManifest[T]].erasure, a).asInstanceOf[T]

определено в org.specs2.mock.MockitoMocker, что на самом деле послужило источником вдохновения для моего решения выше. Но я не могу понять звонок. mock довольно перегружен, и все мои попытки, кажется, заканчиваются вызовом другой версии и не нравятся мои параметры.

Итак, похоже, что Эрик включил поддержку для этого, но я не понимаю, как это сделать.

Обновить

Я определил черту, содержащую следующее:

  def mock[T, A](implicit m: ClassManifest[T], default: A): T = {
    org.mockito.Mockito.mock(
      implicitly[ClassManifest[T]].erasure,
      new Answer[A] {
      def answer(p1: InvocationOnMock): A = default
    }).asInstanceOf[T]
  }

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

implicit val defaultParseResult = None
val mockParser = mock[Parser,Option[MyType1]]

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

Мне все еще было бы интересно, как справиться с этой проблемой, не добавляя эту черту.

Без полного сложно сказать, но не могли бы вы проверить, что метод, который вы пытаетесь имитировать, не является окончательным методом? Потому что в этом случае Mockito не сможет издеваться над ним и вернет null.

Еще один совет, когда что-то не работает, — переписать код с помощью Mockito в стандартном тесте JUnit. Затем, если это не удастся, на ваш вопрос может лучше всего ответить кто-то из списка рассылки Mockito.