Спок - издеваться над методом закрытия Groovy?

Это зависит от того, что вы действительно пытаетесь проверить. Вот один пример, который может быть полезен:

class DirectoryNameHelper {

    /*
     * This is silly, but facilitates answering a question about mocking eachDir
     */
    List<String> getUpperCaseDirectoryNames(File dir) {
        List<String> names = []
        dir.eachDir {File f ->
            names << f.name.toUpperCase()
        }
        names
    }
}

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

import groovy.mock.interceptor.MockFor
import spock.lang.Specification

class EachDirMockSpec extends Specification {

    void 'test mocking eachDir'() {
        setup:
        def mockDirectory = new MockFor(File)
        mockDirectory.demand.eachDir { Closure c ->
                File mockFile = Mock() {
                    getName() >> 'fileOne'
                }
                c(mockFile)

                mockFile = Mock() {
                    getName() >> 'fileTwo'
                }
                c(mockFile)
        }

        when:
        def helper = new DirectoryNameHelper()
        def results
        mockDirectory.use {
            def f = new File('')
            results = helper.getUpperCaseDirectoryNames(f)
        }

        then:
        results == ['FILEONE', 'FILETWO']
    }
}

Сначала я хочу поблагодарить обоих Шаймона Степняка и Джефф Скотт Браун за их соответствующие ответы, которые были действительно проницательными и за которые я проголосовал по этой причине. Я предлагаю, чтобы ОП принял тот из них, который ему больше нравится, не этот, потому что здесь я просто объединяю оба подхода в одну спецификацию, используя один и тот же тестируемый класс и сопоставимое именование переменных в функции. методы. Я также упростил фиктивное использование подкаталогов, чтобы использовать только один фиктивный объект, который возвращает два разных имени файла при последующих вызовах через getName() >>> ['subDir1', 'subDir2'].

Итак, теперь мы можем более легко сравнить оба подхода, которые в основном делают это:

• Подход Szymon заключается в том, чтобы полагаться на встроенные средства Spock, и это то, что следует использовать при тестировании классов Java. OTOH, здесь мы имеем дело с eachDir, специфичной для Groovy вещью. Недостатком здесь является то, что для того, чтобы реализовать этот вид насмешек, нам действительно нужно посмотреть исходный код для eachDir и одного из его вспомогательных методов, чтобы выяснить, что именно нужно заглушить, чтобы все это работало правильно. . Тем не менее, это простое и правильное решение IMO.
• Подход Джеффа смешивает насмешки Спока с собственным MockFor Groovy, из-за чего мне было немного сложнее читать, когда я впервые столкнулся с ним. Но это только потому, что Spock я использую исключительно для тестирования Java-приложений, т.е. я не любитель Groovy. Что мне нравится в этом подходе, так это то, что он работает без изучения исходного кода eachDir.

package de.scrum_master.stackoverflow

import groovy.mock.interceptor.MockFor
import spock.lang.Specification

class MockDirTest extends Specification {

  def "Mock eachDir indirectly via method stubbing"() {
    setup:
    File subDir = Mock() {
      // Stub all methods (in-)directly used by 'eachDir'
      getName() >>> ['subDir1', 'subDir2']
      lastModified() >> 2000
      exists() >> true
      isDirectory() >> true
    }
    File parentDir = Mock() {
      // Stub all methods (in-)directly used by 'eachDir'
      getName() >> 'parentDir'
      listFiles() >> [subDir, subDir]
      exists() >> true
      isDirectory() >> true
    }
    def helper = new DirectoryNameHelper()

    when:
    def result = helper.getUpperCaseDirectoryNames(parentDir)

    then:
    result == ['SUBDIR1', 'SUBDIR2']
  }

  def "Mock eachDir directly via MockFor.demand"() {
    setup:
    File subDir = Mock() {
      getName() >>> ['subDir1', 'subDir2' ]
    }
    def parentDir = new MockFor(File)
    parentDir.demand.eachDir { Closure closure ->
      closure(subDir)
      closure(subDir)
    }
    def helper = new DirectoryNameHelper()

    when:
    def result
    parentDir.use {
      result = helper.getUpperCaseDirectoryNames(new File('parentDir'))
    }

    then:
    result == ['SUBDIR1', 'SUBDIR2']
  }

  static class DirectoryNameHelper {
    List<String> getUpperCaseDirectoryNames(File dir) {
      List<String> names = []
      dir.eachDir { File f ->
        names << f.name.toUpperCase()
      }
      names
    }
  }

}

Вы не можете имитировать eachDir таким образом, потому что этот метод не принадлежит классу File — он добавляется динамически через ResourceGroovyMethods. Вместо этого вам придется издеваться над методами listFiles(), exists() и isDirectory(), например:

    File mockParentDir = Mock(File) {
        getName() >> 'parent_dir'
        listFiles() >> mockSubdirs
        exists() >> true
        isDirectory() >> true
    }

Имитация методов exists() и isDirectory() является обязательной, потому что mock возвращает значения по умолчанию, если вы их не укажете, а для логического значения по умолчанию используется значение false — в этом случае вы получите FileNotFoundException. Вам придется сделать то же самое для mockSubdirs, если вы ожидаете, что он будет содержать каталоги.

Вот примерный тест, который показывает правильное издевательство:

import spock.lang.Specification

class MockDirSpec extends Specification {

    def "test mocked directories"() {
        setup:
        def mockSubdirs = []
        mockSubdirs << Mock( File ){
            getName() >> 'some subdir'
            lastModified() >> 2000
            exists() >> true
            isDirectory() >> true
        }

        File mockParentDir = Mock(File) {
            getName() >> 'parent_dir'
            listFiles() >> mockSubdirs
            exists() >> true
            isDirectory() >> true

        }

        def cut = new ClassUnderTest()
        cut.myDirectory = mockParentDir

        when:
        def names = cut.names()

        then:
        names == ['some subdir']
    }

    static class ClassUnderTest {
        File myDirectory

        List<String> names() {
            def dirNames = []
            myDirectory.eachDir {
                dirNames << it.name
            }
            return dirNames
        }
    }
}

Насмешка eachDir - недостатки

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

def dirNames = []
myDirectory.eachDir{ 
    dirNames << it.name
}

дает разные результаты в зависимости от того, на что ссылается переменная myDirectory. Например:

• если myDirectory указывает на пустой каталог, dirNames оказывается пустым
• если myDirectory указывает на каталог, содержащий несколько текстовых файлов, dirNames оказывается пустым
• если myDirectory указывает на каталог, содержащий 2 подкаталога и 10 текстовых файлов, dirNames в конечном итоге содержит 2 элемента, имена этих подкаталогов

Если мы имитируем eachDir, чтобы он всегда принимал одни и те же фиксированные входные файлы, не имеет значения, вызываем ли мы его для переменной, представляющей пустой каталог, или для каталога, содержащего 2 подкаталога и несколько текстовых файлов - результат в обоих случаях всегда один и тот же.

В этом случае для меня имеет больше смысла издеваться над вводом — каталогом, представленным как File. Благодаря этому вы можете моделировать без создания реального файла:

• пустой каталог
• каталог с одним текстовым файлом
• каталог с одним подкаталогом
• каталог с кучей подкаталогов и несколькими текстовыми файлами
• и т.п.

И вам не нужно имитировать поведение метода eachDir, что является огромным преимуществом.

Еще одним преимуществом является то, что вам не нужно менять код приложения — вы по-прежнему можете использовать функцию eachDir внутри. Когда вы имитируете входные файлы вместо имитирования метода eachDir, вы просто предоставляете тестовые данные, которые хранятся в памяти, а не в файловой системе. Представьте себе создание желаемой файловой структуры и изучение того, чем эти экземпляры File представлены во время выполнения с помощью отладчика — вы можете воспроизвести то, что возвращают все общедоступные методы из класса File, используя значения, взятые из реальной файловой системы. Это может дать вам хорошую симуляцию «в памяти» того, как выглядит конкретный каталог при сохранении в файловой системе. И вы используете его в качестве входных данных в своем тесте для имитации того, что происходит во время выполнения. Вот почему я считаю насмешку над eachDir вредной — она создает сценарий, который не отображается в среде выполнения.

Также есть хороший пост в блоге от дяди Боба о насмешках, который можно резюмировать следующим выводом:

"Вкратце, однако, я рекомендую вам экономно использовать имитацию. Найдите способ тестирования — спроектируйте способ тестирования — вашего кода, чтобы он не требовал имитации. Зарезервируйте имитацию для архитектурно значимых границ; и тогда будьте безжалостны. Это важные границы вашей системы, и ими нужно управлять не только для тестов, но и для всего."

Источник: https://8thlight.com/blog/uncle-bob/2014/05/10/WhenToMock.html