Создать модульный тест для функции архива fs

Question

У меня есть следующая функция, которая работает, как ожидалось. Теперь я хочу создать для него модульный тест. Проблема в том, что я использую файловую систему, и я не могу понять, как это сделать с помощью каких-то насмешек или другого решения. Любая идея, как это можно сделать просто в Go? Должен ли я действительно создать файлы и проверить с помощью модульного теста? Я боюсь, что в некоторых системах это будет работать, а в некоторых - ломаться (winodos / mac / linux)

Это рабочая функция:

func Zipper(src string,artifact string,target string) error {

    zf, err := os.Create(artifact)
    if err != nil {
        return err
    }
    defer zf.Close()

    ziper := zip.NewWriter(zf)
    defer ziper.Close()

    fileInfo, err := os.Stat(src)
    if err != nil {
        return err
    }

    var bs string
    if fileInfo.IsDir(); len(target) > 0 {
        bs = target
    } else {
        bs = filepath.Base(src)
    }

    if bs != "" {
        bs += "/"
    }

    filepath.Walk(src, func(path string, info os.FileInfo, err error) error {
        if err != nil {
            return err
        }

        if info.IsDir() {
            return nil
        }

        header, err := zip.FileInfoHeader(info)
        if err != nil {
            return err
        }

        if bs != "" {
            header.Name = filepath.Join(strings.TrimPrefix(path, bs))
        }

        header.Method = zip.Deflate

        writer, err := ziper.CreateHeader(header)
        if err != nil {
            return err
        }

        file, err := os.Open(path)
        if err != nil {
            return err
        }
        defer file.Close()
        _, err = io.Copy(writer, file)
        return err
    })

    return err
}

Я прочитал следующее, но это не сильно помогает в моем случае Как смоделировать / абстрагировать файловую систему в go?

Answer 1

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

Go (и их пользователи) не очень педантичны в различении «юнит-тестов» и «интеграционных» тестов. Взгляните на stdlib о том, как тестировать такие вещи. Гораздо важнее написать соответствующие тесты, чем получить ребяческий доступ к fs. (Обратите внимание, что файловая система и база данных являются технически внешними системами, но в реальной жизни вы не можете скомпилировать код Go без файловой системы, поэтому изоляция теста от этой «внешней системы» нелепа.)

Answer 2

Ну, вы можете найти способ безопасного управления файловой системой или найти решение где-нибудь еще. Какова ответственность этой функции? Должен ли он подготовить zip-файл или записать его в файловую систему?

Я предлагаю вам исключить создание файла из этой функции и изменить функцию на:

func Zipper(src string, dst io.Writer, target string) error {
    ziper := zip.NewWriter(dst)
    defer ziper.Close()

Таким образом, для целей тестирования вы можете предоставить простой буфер, а в производственном процессе использовать вашу любимую файловую систему!

Answer 3

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

func TestZipper(t *testing.T) {
    // Create temporary files
    defer func() {
        // Clean up temporary files
    }()
    t.Run("group", func(t *testing.T) { // This is necessary so the above defer function doesn't run too soon
        // your actual tests
    })
}